Re: Any Compilation Gurus?

[bob@xxxxxxx]

>So a staticly compiled application doesn't even need libc/glibc?
Not in principal, or directly. However, the it stepping on Supermans 
cape to run a static binary on a system that has TOO different a libc
than the one on which it was formed, but for other reasons. Things 
are pretty much guaranteed to be forward compatible, but not backwards-
compatible. Your static binaries from the 2.0.35 days MIGHT (very 
probably) run on 2.4.x systems with much newer libc's, and so on, but
don't come whining to me if they don't! :) I would expect that there are 
other problems with this code (like how some kernel calls are made, or
similar API issues) that would force a recompile (or a relink).

>Does the a.out/ELF change effect the format of shared libraries as well?
>(I seem to remember that it does)
Yes.
 
>>Dynamically linked libraries are NOT linked at compile time, but the
>>linker (NOT ld, but ld.so or ld-linux.so, for example) instead checks that
>Right, this is what ldd reports.  There are some variables that
>determine how this works,  like LD_LIBRARY_PATH adds directories
>searched for libraries BEFORE(?) those listed in /etc/ld.so.conf.
Yes, some of the really really nice things libtool does is keep all this
sort of stuff straight, which removes it from every damn Makefile in the
world, and keeps Makefile readers (like us) saner (and with less eye-watering).

>But what do LD_PRELOAD and LD_PRELOAD_PATH do?  I know this is used by
>ESD to somehow capturing calls to open /dev/dsp.  Are these standard
>libraries,  and what is the diff between having these PRELOADed verses
>just in the path?
Oh, beats me! Now you're asking me to READ the libtool script?! :)
I know there are a number of tricks, and some of this tends to cache 
libraries in memory for faster linking, or otherwise give libraries so 
designated preferential treatment. Not only does libtool give us better
Makefiles, it also gives us better (and packaged) performance. If you 
think some linking jobds take a long time now, imagine doing some of 
that work without caching, etc....

>Something else I can't find documented is LD_ASSUME_KERNEL,  which I've
>seen frequently as "LD_ASSUME_KERNEL=2.2.5" in commercial products like
>Informix.  Take it out and they're dead as a post.  Any idea what that
>does?
Not really, but I can probably hum a few bars.... :)
Seriously, it would seem that many of these products may be dependent on
some kernel feature (or specifically some data declarations that come with
(starting at) a particular kernel release. If you can look at some of the
Informix header files, they might set them up...take it away and all their
#ifdef's (and so on) break.
                                                      Regards,
                                                       ---> RGB <---