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

[Dave Love]

[Attempting to post onto Cc:d lists that bounced my reply.]

Kurt Reimer <greimer@fccc.edu> writes:

>> That's wrong.  What if you now install gcc 4 too?
>>
>       I don't know.

[It was a rhetorical question.]

> There does not appear to be any provision for versions of static
> libraries, like there is for shared ones.

The different versions of libgcc live in the tool- and target-specific
gcc directories.

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

They work (as advertised and expected) on 10.

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

I hope you don't have anything linked against them.  Building against
copies or symbolic links to the .a files elsewhere is reliable.

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

[At configure time, I hope.]

>       If forced to choose I'd keep shared objects over static ones,
> but I don't like being forced to choose.

Then don't pay Sun, or perhaps pay them much more.  Now you can
maintain a fork of OpenSolaris and find out what's involved.

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

Building cfengine proves you can link statically against a library,
and it's not likely that would become impossible.  You just don't have
static system libraries.

>       At any rate, even with my somewhat lame gcc there is the
> above-described work-around to the "libgcc.so" error.

Others probably won't want shot in foot, though.