Re: Problems configuring cfengine 2.1.17 on Solaris10

[Mark Burgess]

On Fri, 2005-12-23 at 10:29 -0500, Kurt Reimer wrote:
> Mark,
>       AFter exchanging some posts with Jason Martin (they're in the 
> archive for this list), we've figured out that the problem does not lie 
> with any difficulty in finding and resolving references to the BerkeleyDB 
> libraries. The -L and /or -R compile switches referencing 
> /usr/local/Berkeyey.4.4/lib seem to handle this.
> 
>       Instead, the configure script can't find libgcc_s.so.1. When I 
> define LD_LIBRARY_PATH=/usr/local/lib (where libgcc_s.so.1) lives, the
> original configure script works. The GCC documentation says that libgcc is 
> just some internal routines, and also offers the "-shared-libgcc" and 
> "-static-libgcc" switches. I tried using the "-static-libgcc" switch and
> found that it didn't work, even after I went into /usr/local/lib and 
> created a libgcc.a symlink to 
> /usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2.sparcv9/libgcc.a, where 
> it was buried. Maybe this is because of the way that the GCC package was 
> built (if "-static-libgcc" was going to be supported the build would have 
> put libgcc.a in /usr/local/lib), or maybe it's because I didn't use 
> "-static-libgcc" when building the BerkeleyDB. I did find that I could 
> force the use of static BerkeleyDB libraries by removing the shared ones, 
> and then at least the test program executed without any LD_LIBRARY_PATH
> definition. There probably are compiler and linker switches that are the
> "right" way to make this happen, but I don't know what they are.
> 
>       I don't like the idea of having to distribute libgcc_s.so.1 and a 
> custom library search path definition, along with the cfengine software, 
> to any system where I want to run cfengine. There are a number of 
> experiments to try involving custom configurations and builds of 
> cfengine, the BerkeleyDB, and GCC itself.
> 
>       I was also somewhat upset to learn that Sun Microsystems no longer 
> supports static executables, in that they don't supply static versions of 
> the standard libraries in Solaris10! I guess if you want static builds you 
> need to go to the GNU standard libraries, or something like that. That's 
> the sort of thing I expect from Microsoft, not Sun.
> 
> Yours,
> 
> Kurt Reimer
> Fox Chase Cancer Center

Yes, this is an odd development. So, it is *yet another Red Hat C
library problem"? Dear dear...what are they up to these days?

M