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?
I don't know. Maybe my libgcc.a off in the 3.3.2 subdirectory
would get hosed, or maybe the symlink would get deleted and the gcc 4
version of libgcc.a would be put in /usr/local/lib. (I bet if I built
gcc from source, the install would do the right thing.) There does not
appear to be any provision for versions of static libraries, like there
is for shared ones. Anyway, I'm just trying to make my shared library
dificulties go away. I tried replacing the symlink with a real copy of
libgcc.a, and going back and recompiling the Berkeleydb with the
-static-libgcc switch, and things didn't behave any better.
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 looked at the blastwave.org packages, but lost some confidence
in them when all the ones in the Solaris10 subdirectory had solaris5.8 in
their names. (Maybe I picked a flaky mirror site?).
I finally was able to do away with the "libgcc.so.." error by the
brute force method of removing all the shared versions of the Berkeleydb
libraries from their install directory. This seems to force the use of the
static ones. Oddly, right after this step I got a linker error flagging
"fdatasync" as an undefined symbol when linking cfagent. It went away
when I added "-lposix4" to the linker switches (it wasn't in libc).
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.
If forced to choose I'd keep shared objects over static ones,
but I don't like being forced to choose. If I want to build a
statically-linked version of, say, httpd, and waste all my memory running
500 iterations of it then I should be allowed to do so! The Unix and 'C'
philosophy is that you're free to shoot yourself in the foot whenever
you'd like, right? Now, if I write some little utility that happens to
use a routine from an unusual library, I can't run it on any other
computer unless I bring over that library, too.
At any rate, even with my somewhat lame gcc there is the
above-described work-around to the "libgcc.so" error.
Yours,
Kurt Reimer
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
