Re: ? 4GL compile/link w/ .so (using gcc)

How-do from Texas... I wanted to add an update to my IFM"X-file", I think we found our culprit (though I'm not yet sure of the most elegant solution). We have a shell script which, for each library we are compiling, crunches through parallel directories which contain successive versions of the library, compiles the 4gl's, and then does the following: if test "$shared_libs" then mssg -n " Loading object files into shared library $lib" ar_mssg=`ld -G -o $lib $good_list 2>&1 > /dev/null` else mssg -n " Loading object files into $lib" ar_mssg=`ar ${fgmkArOpt:=rc} $lib $good_list 2>&1 > /dev/null` fi For the first time we are experimenting with creating .so files instead of .a files, and missed the ramifications of how these two branches differ. It looks like the ld invocation creates a new .so each time (the "ld -o"), but the ar has the capability to replace already-archived .o files with newer ones found in successive directories. I'm still not sure what the most elegant solution is to our situation, but I think I understand what's happening now. Special thanks to Dualta of Informix-Ireland (suggested I use "nm" to get an idea of what's inside of our .so files). That was the ice-breaker. Before I go, I just want to let y'all X-Files fans out there know that last Sunday's episode was just not plausible. As one of my buddies pointed out, vampires live a long time, and trailer-park vampires in Texas would've done got blowed away by a tornayduh by now. -- John Bitsche