Kurt Reimer <[EMAIL PROTECTED]> writes: > 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,
That's wrong. What if you now install gcc 4 too? > 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), No. (If you'll believe a former gcc maintainer.) I haven't seen the start of this, but you appear just to have a hosed compiler setup. You can get gcc (and db) packages which work from blastwave.org. The gcc-4.0 one certainly builds cfengine OK on Solaris 10 (without a shared libgcc). > 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. I don't want to be an apologist for them, but I doubt Sun will land you in dll hell like Microsoft, especially since ELF libraries will be versioned. (Irix took that decision long ago, by the way.) There are good reasons to use shared objects. The real pain is the that cfengine requires a non-system version of db (and libcrypto?) which need to be linked statically because `cfexecd -L' isn't useful, since cfexecd links them itself. You either risk distributing binaries which won't load and break the client, or you're statically linked against an openssl library that may get a security alert. _______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
