Re: building 2.4.4p1 under Solaris 9 with native-built gcc-3.3(fwd)
On Wed, 2003-07-30 at 17:45, Craig Dewick wrote: > Further to this issue, > > I have now tried, for the sake of experimentation (after a few people have > contacted me privately suggesting it), setting LD_LIBRARY_PATH. I set it > just to have /usr/local/lib in the variable. As I understand things. The LD_LIBRARY_PATH variable is used at run time as an additional search path for loadable modules (.so files). If you have it set while compiling, it will search that path for loadable modules but will not include it in the compiled in path to search for them. Using the -R (or -L) flag with the compiler adds the path to the search list built into the binary at build time. Also, have a look at the crle command. It lets you change the default search path for shared libraries at a system level (instead of having to always set LD_LIBRARY_PATH). -- Ean Kingston <[EMAIL PROTECTED]>
Re: building 2.4.4p1 under Solaris 9 with native-built gcc-3.3 (fwd)
Further to this issue, I have now tried, for the sake of experimentation (after a few people have contacted me privately suggesting it), setting LD_LIBRARY_PATH. I set it just to have /usr/local/lib in the variable. Strangely, the whole Amanda 2.4.4p1 source tree build without a hitch, and 'genversion' has no problem locating 'libgcc_s'. A run of 'ldd' over the binary shows it finds libgcc_s in /usr/local/lib as it's meant to do via the run-time lib search path which is supposed to be compiled in by the linker. As soon as I unset LD_LIBRARY_PATH, 'genversion' fails to find libgcc_s again. What does this indicate? Is there something wrong with the Amanda makefiles which cause the LDFLAGS setting to be ignored? I'll see if I can find out more today. I'm puzzled why actually setting LD_LIBRARY_PATH works since it's not required and the build process should work properly without it when a run-time lib search path is compiled in. Craig. -- Email by Craig Dewick (tm). Home page at "lios.apana.org.au/~cdewick". "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]". Explore and enjoy my public-domain Sun Microsystems technical data archive at "www.sunshack.org", "www.sunshack.net" or "www.sunshack.info".