From owner-freebsd-current Sat Sep 21 03:40:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA01808 for current-outgoing; Sat, 21 Sep 1996 03:40:46 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA01773 for ; Sat, 21 Sep 1996 03:40:36 -0700 (PDT) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.7.6/8.7.3) id MAA23552 for current@freebsd.org; Sat, 21 Sep 1996 12:40:33 +0200 (SAT) From: John Hay Message-Id: <199609211040.MAA23552@zibbi.mikom.csir.co.za> Subject: Some shared library problems To: current@freebsd.org Date: Sat, 21 Sep 1996 12:40:33 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL24 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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