...
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
I've looked at 32/64 RHEL4/RHEL5 support being properly built into CMX. It's a nightmare. Several things conspire to just make it a royal pain:
1) The AFS system does not distinguish between RHEL4 and RHEL5 in it's 'fs sys' response ... bit of a shame because CMT uses that to generate the CMT tag!
2) Other methods of determining the host/OS/bit-width are completely flaky. The only way I've found to develop this is to inspect the linux kernel version ... and that would only work on redhat-linux machines!
3) Even if I could distinguish RHEL4/5, what does that really mean? Unless Rehat pull another backward incompatibity trick (libstdc++ changed significantly from RHEL3 to RHEL4 ... hence our recent problems), then anything built with RHEL4 should be fine under RHEL5. The only real distinction I have found is a significant bump in the gcc compiler version (3.4.6 to 4.1.2). That might sound bad, but FSW is all written in C, which is far less vulnerable to compiler upgrades.Nevertheless, I'm gradually retrofitting CMX where I can. Which brings me to the next problem. Along with the code itself, CMX versions the tools it uses. CMX is itself a CMX package. Bootstrap problem. When (for instance) FSW build B1-1-3 was declared, it froze out the version of CMX associated with it. If I have to modify CMX itself to produce 32/64 RHEL4/RHEL5 builds, then technically, I'm breaking the build (this did not apply when rebuilding on rhel4-32 ... no modifications were needed ... just needed to log into a machine with the right architecture/OS).
So I'm exploring another method for producing all the variations. It's far too hand-held for my taste and will have poor traceability, but it's probably all ground software needs. The basic principle is to bugger a minimum number of CMX files (so far that's just the requirements file and the cmx_link.pl script). The modifications amount to redefining what our "linux-gcc" tag means. If and when the build completes, rename all directories names "linux-gcc" to an architecture specific name (e.g. "rhel5-32"), then repeat for the next architecture. I'm practicing on the B1-1-3 build. If I can get this going, I'll hand off the procedure to Kim, so that he can do the same for other FSW builds needed by ground.
...
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.