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

[Kurt Reimer]

> > 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