[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems configuring cfengine 2.1.17 (&.18) on Solaris10

From: Kurt Reimer
Subject: Re: Problems configuring cfengine 2.1.17 (&.18) on Solaris10
Date: Wed, 28 Dec 2005 11:08:23 -0500 (EST)

found that it didn't work, even after I went into /usr/local/lib and
created a libgcc.a symlink to

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.


Kurt Reimer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]