[Attempting to post onto Cc:d lists that bounced my reply.] Kurt Reimer <[EMAIL PROTECTED]> 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. _______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
