From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Peter O'Gorman Newsgroups: gmane.lisp.guile.bugs,gmane.comp.gnu.libtool.bugs Subject: Re: Mac OS X .dylib not working Date: Thu, 4 Feb 2010 09:34:45 -0600 Message-ID: <20100204153444.GC23972@tw.local> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1265297821 11748 80.91.229.12 (4 Feb 2010 15:37:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2010 15:37:01 +0000 (UTC) Cc: bug-guile@gnu.org, Ken Raeburn , bug-libtool@gnu.org, Bob Friesenhahn To: Hans Aberg Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Feb 04 16:36:58 2010 Return-path: Envelope-to: guile-bugs@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 1Nd3lJ-0006X5-5z for guile-bugs@m.gmane.org; Thu, 04 Feb 2010 16:36:57 +0100 Original-Received: from localhost ([127.0.0.1]:53376 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd3lI-0003Yo-JH for guile-bugs@m.gmane.org; Thu, 04 Feb 2010 10:36:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nd3jZ-0002r0-Mo for bug-guile@gnu.org; Thu, 04 Feb 2010 10:35:09 -0500 Original-Received: from [199.232.76.173] (port=60321 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd3jZ-0002qh-5G for bug-guile@gnu.org; Thu, 04 Feb 2010 10:35:09 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nd3jT-0002u2-4v for bug-guile@gnu.org; Thu, 04 Feb 2010 10:35:07 -0500 Original-Received: from pogma.xen.prgmr.com ([68.68.97.8]:42635) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nd3jR-0002si-Vo; Thu, 04 Feb 2010 10:35:02 -0500 Original-Received: from tw.local (S010600095b5f1590.wp.shawcable.net [24.76.170.162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pogma.xen.prgmr.com (Postfix) with ESMTP id D1A63BF60E; Thu, 4 Feb 2010 15:34:56 +0000 (UTC) Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:4499 gmane.comp.gnu.libtool.bugs:7251 Archived-At: On Thu, Feb 04, 2010 at 04:21:27PM +0100, Hans Aberg wrote: >> When libtool support for Mac OS X was added, there was no way to load >> .dylib files, not much software had any knowledge of Mac OS X, and >> quite >> a lot of things had hardcoded ".so" when loading files at runtime, so >> to >> accomodate this, .so was chosen as the extension when creating >> loadable >> modules (MH_BUNDLE) and .dylib when creating MH_DYLIB. Changing >> this now would cause far too many problems. > > 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. >> 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? > ---- > $ 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? Anyway, I am convinced that this is a packaging bug. Peter -- Peter O'Gorman http://pogma.com