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.
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, 2009basically, 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.
Our current CMT requirements for OBF based on B1-1-3:
Options |
Consequences |
|---|---|
Convince FSW to exert effort to build on 64 bit machines |
Work cannot start until February |
Build FSW (or portions of it) ourselves using CMT |
|
Ask FSW to at least support gcc 4 |
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 |