From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hans Aberg Newsgroups: gmane.comp.gnu.libtool.bugs,gmane.lisp.guile.bugs Subject: Re: Mac OS X .dylib not working Date: Thu, 4 Feb 2010 17:52:24 +0100 Message-ID: <2294A181-3BA6-4B11-A41F-816D54FE215A@math.su.se> References: <20100202064208.GC5651@gmx.de> <657AF3C8-764A-4DDE-918F-F1D97DA8E8EC@math.su.se> <359C630D-FEA1-4422-91B5-6FB0DFD6941D@raeburn.org> <675379A5-A6C5-4331-B82B-1E1F975C359A@math.su.se> <470370CA-2B7D-49F3-B48C-70B0731757F9@math.su.se> <20100204134916.GB23972@tw.local> <20100204153444.GC23972@tw.local> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1265303209 5292 80.91.229.12 (4 Feb 2010 17:06:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2010 17:06:49 +0000 (UTC) Cc: bug-guile@gnu.org, Ken Raeburn , bug-libtool@gnu.org To: Peter O'Gorman Original-X-From: bug-libtool-bounces+gnu-bug-libtool=m.gmane.org@gnu.org Thu Feb 04 18:06:46 2010 Return-path: Envelope-to: gnu-bug-libtool@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nd5A7-0001O8-JU for gnu-bug-libtool@m.gmane.org; Thu, 04 Feb 2010 18:06:39 +0100 Original-Received: from localhost ([127.0.0.1]:33789 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd4x1-0001ao-8w for gnu-bug-libtool@m.gmane.org; Thu, 04 Feb 2010 11:53:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nd4wa-0001RK-Us for bug-libtool@gnu.org; Thu, 04 Feb 2010 11:52:41 -0500 Original-Received: from [199.232.76.173] (port=38249 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd4wa-0001Qu-5M for bug-libtool@gnu.org; Thu, 04 Feb 2010 11:52:40 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nd4wZ-0004iF-4k for bug-libtool@gnu.org; Thu, 04 Feb 2010 11:52:39 -0500 Original-Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]:40723) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nd4wW-0004ha-EW; Thu, 04 Feb 2010 11:52:36 -0500 Original-Received: from h131n2-fre-d2.ias.bredband.telia.com (78.72.157.131) by pne-smtpout2-sn2.hy.skanova.net (7.3.140.3) (authenticated as u26619134) id 4B5C677E00192FF8; Thu, 4 Feb 2010 17:52:28 +0100 In-Reply-To: <20100204153444.GC23972@tw.local> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: bug-libtool@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports for the GNU libtool shared library maintenance tool List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-libtool-bounces+gnu-bug-libtool=m.gmane.org@gnu.org Errors-To: bug-libtool-bounces+gnu-bug-libtool=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.gnu.libtool.bugs:7253 gmane.lisp.guile.bugs:4501 Archived-At: On 4 Feb 2010, at 16:34, Peter O'Gorman wrote: >> Not really: 10.4 and earlier are obsolete, and 10.5 is becoming. On >> 10.5, just ordinary load is fine. > 10.4 and earlier are not obsolete, sorry. The only computers that can't run 10.4 are G3 and they are really to slow. At least the one I installed it on. !0.5 runs fine also on a G4 350 Ghz I tried it on. >>> So, long story short, ltld looks for ".so" because that is the >>> extension >>> used for loadable modules. >> >> Well, that is not a part of the UNIX standard, and therefore not >> POSIX, >> which is nowadays a subset. > > Which part of POSIX standardizes library extensions? None. There is some mentioning about c99 and make about .c, .f and .o files, but really no requirements. You can use those for portability reasons. Or at least that is what they say one the UNIX standardization list. >> ---- >> $ lilypond empty.ly >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libintl.8.dylib >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libguile.17.dylib >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libltdl.7.dylib >> GNU LilyPond 2.13.7 >> dyld: loaded: /usr/local/lib/libguile-srfi-srfi-1-v-3.3.dylib >> dyld: loaded: /usr/local/lib/libguile.17.dylib >> dyld: loaded: /usr/local/lib/libintl.8.dylib >> dyld: loaded: /usr/local/lib/libgmp.3.dylib >> dyld: loaded: /usr/local/lib/libltdl.7.dylib >> Segmentation fault > > So lilypond starts up fine, but guile's first dlopen() for > libguile-srfi-srfi-1-v-3.3 causes the library in /usr/local/lib to be > loaded (and its dependent libraries, including another libguile, > libintl, and libltdl). Ensuring that the search path is correct would > fix this problem, look at setting the LTDL_LIBRARY_PATH environment > variable, perhaps? Does what flags does libtool use when compiling dynamic libraries? One can compile with name lookup table and direct jump table. The former, it seems would not break if version differ, if they contain the same function. > Anyway, I am convinced that this is a packaging bug. They will probably have to do something to make sure their own libraries are called - that's their bug. Hans