Options |
Consequences |
---|---|
Convince FSW to exert effort to build on 64 bit machines |
Work cannot start until February and it is unclear how much time will be necessary or how many FSW packages will require updates. |
Build FSW (or portions of it) ourselves using CMT (actually do we want to use FSWs CMX build system?) |
Can we afford the resources to do that? Building is one thing - working through the pilie of issues for 64 bit or gcc 4 is another and would still likely require a lot of interaction with the FSW team. |
Ask FSW to at least support gcc 4 but stay with 32 bit (RHEL5-32) |
May be as much effort as moving to 64 bit and gcc 4 |
Stay with what we have: FSW built on RHEL4-32 |
We would have to upgrade to this newer FSW build to take advantage of it, hopefully not too labor intensive as the OBF portion is supposedly unchanged. |
Stop using OBF and write our own filter code as we did in the old days |
Risk of not fully duplicating the existing OBF code. Future changes to OBF in FSW would then have to be reflected in our version (it is unclear how much more modification to OBF there really will be though). |
Minutes from Meeting Friday October 23, 2009
Tony Waite, Jana and Gregg Thayer, Heather Kelly
Currently offline is using FSW B1-1-3. Tony has no way to estimate how much effort it is to go to 64 bit without actually going through the exercise. Tony and JJ are unavailable. Jana and Gregg are unavailable until at least February. Tony was wondering about having offline stick with 32 bit on RHEL5 & RHEL4 as it is unclear what benefit we get from 64 bit anyhow. That way we could pursue a gcc4.1 build - though to scope out the amount of work required would be similar to just forging ahead on RHEL5-64. I'm not sure how content offline would be with 32 bit builds, but we could consider it. Tony wanted to discuss with Tracy how we build and use OBF. Heather mentioned that we use the FSW shareables on Linux, while on Windows Tracy is building from source.
Note from Tracy Oct. 23, 2009
basically, in order to use the various filters we have no choice but to use their higher level interface to it, since the filters expect to see the data in a particular format and we need their higher level stuff to handle the setup of that format. Without a HUGE amount of work on our part, we aren't going to change that. Anyway, when we went to the model of using the FSW libraries I had discussions with JJ and he agreed that was a good way to go, even though it did mean bringing in a lot of extra FSW dependent libraries. .
The goal is to use THE filter code that is running on the LAT. We could back off and have our own filters but then you run the risk that you are not really duplicating their operation. In addition, any future changes to the filters will require parallel changes to our stuff so we'll need to maintain an "expert" to do that. Since my boss tells me I am supposed to be doing other things now, I don't know who that person is.
So, in short, if the collaboration requires that the filters are part of Gleam then the FSW group needs to get their hands dirty one way or the other.
An option is to go back to building the stripped down windows version of OBF on linux. Since I do this with a cmt requirements file its probabbly not that difficult to do. I guess I don't know anything about 64 bit machines and what has to be done with cmt to get a requirements file to do a build this way, but we could look at it.
Email from Tony Waite after first look at FSW and RHEl5-64
FSW B1-1-3 on rhel5-32: (major characteristic ... compiler is gcc 4.1.2)1) New compiler generates some new global symbols. That's a no-no in a CDM style shareable (a shareable that exposes global symbols cannot be guaranteed to be unloadable). To make progress, I assumed that the symbols involved were not linked against and added them to the "forgive" list.2) New compiler is very fussy about placement of "laddr" objects. Results in a fatal error in package PBS (fixed packet allocator). Didn't try to fix.FSW B1-1-3 on rhel4-64: (major characteristic ... 64 bit width ... d'oh)1) Has new/different compiler macros to express architecture. Package PBI does not understand/recognise them, meaning that the "Endianness.h" header file turns round and complains that it can't determine machine endian-ness. Didn't try to fix.