Date: Sat, 21 Sep 1996 12:40:33 +0200 (SAT) From: John Hay <jhay@mikom.csir.co.za> To: current@freebsd.org Subject: Some shared library problems Message-ID: <199609211040.MAA23552@zibbi.mikom.csir.co.za>
index | next in thread | raw e-mail
Hi,
I picked these up while trying to build a -CURRENT SNAP release on a
2.1.5 machine. Now I do understand that it might be considered cheating
a little, but it is the only PPro 200MHz that we have here and it must
run 2.1.5. I thought that because the make release fase will do a make
world in the chrooted area the end result should be an -current snap. :-)
The first problem I ran into was the libgnumalloc that gets removed and
then reappear as a link to libfakegnumalloc in ${CHROOTDIR}/usr/lib/compat.
Maybe there should be a "ldconfig -m /usr/lib/compat" after such a drastic
step? I think I can get past this by setting the LD_LIBRARY_PATH envirenment
variable. This one does not bother me too much, although I would like a
solution to this.
The one that I think might bite us somewhere is libgnuregex.so.2.0 that
now (in -current) have locale stuff in that needs libc.so.3.0 while
the libgnuregex.so.2.0 in 2.1.5 did not have it. The result of this is
that a program compiled with libgnuregex.so.2.0 and libc.so.2.x won't
run with the new libgnuregex.so.2.0 installed. Where I noticed it was
when awk was used during the compilation of usr.bin/kdump. Maybe the
major version number of a library should be bumped if it starts to
depend on another library? I think this counts as a major interface
change.
Any ideas anybody? Maybe I should also just say that I do have another
machine that runs current and I can probably get by these things
manually. It just seem that the latest "make world" target with its
inclusion of the bootstrap target is so close to be able to really
take you from 2.1.5 to current.
John
--
John Hay -- John.Hay@mikom.csir.co.za
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609211040.MAA23552>