From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Peter O'Gorman Newsgroups: gmane.comp.gnu.libtool.bugs,gmane.lisp.guile.bugs Subject: Re: Mac OS X .dylib not working Date: Thu, 4 Feb 2010 07:49:17 -0600 Message-ID: <20100204134916.GB23972@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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1265293389 26910 80.91.229.12 (4 Feb 2010 14:23:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2010 14:23:09 +0000 (UTC) Cc: bug-guile@gnu.org, Ken Raeburn , bug-libtool@gnu.org To: Hans Aberg Original-X-From: bug-libtool-bounces+gnu-bug-libtool=m.gmane.org@gnu.org Thu Feb 04 15:23:06 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 1Nd2bW-0001GH-Mn for gnu-bug-libtool@m.gmane.org; Thu, 04 Feb 2010 15:22:47 +0100 Original-Received: from localhost ([127.0.0.1]:60394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd2bV-00084U-MY for gnu-bug-libtool@m.gmane.org; Thu, 04 Feb 2010 09:22:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nd2ay-0007qX-54 for bug-libtool@gnu.org; Thu, 04 Feb 2010 09:22:12 -0500 Original-Received: from [199.232.76.173] (port=54519 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd2aw-0007pj-Tg for bug-libtool@gnu.org; Thu, 04 Feb 2010 09:22:10 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nd2ar-0007f0-9i for bug-libtool@gnu.org; Thu, 04 Feb 2010 09:22:09 -0500 Original-Received: from pogma.xen.prgmr.com ([68.68.97.8]:58350) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nd2ao-0007dz-Gi; Thu, 04 Feb 2010 09:22: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 853D5BF60E; Thu, 4 Feb 2010 13:49:23 +0000 (UTC) Content-Disposition: inline In-Reply-To: <470370CA-2B7D-49F3-B48C-70B0731757F9@math.su.se> 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-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:7249 gmane.lisp.guile.bugs:4497 Archived-At: On Thu, Feb 04, 2010 at 01:40:07PM +0100, Hans Aberg wrote: > On 2 Feb 2010, at 17:52, Bob Friesenhahn wrote: > >> Under OS-X (Leopard and later), the 'dtruss' program can be used to >> see what is really going on. > > While at it, I found another problem involving libltdl.7.dylib, > guile-1.8.7 and lilypond 2.13.7: > > When upgrading guile using libtool-2.2.6b, lilypond broke, the one which > is in an Application distribution: > /Applications/LilyPond.app/Contents/Resources/bin/guile > It has its own > /Applications/LilyPond.app/Contents/Resources/lib/libltdl.7.dylib > > However, dtruss shows that segmentation fault is caused when calling > /usr/local/lib/libltdl.7.dylib > > When I move this to another name, then lilypond works, but dtruss now > shows that it calls > /usr/lib/libltdl.7.dylib Sorry, I missed most of this thread as I was travelling. What does otool -L /Applications/LilyPond.app/Contents/Resources/bin/guile say? Which libltdl.7.dylib does it list? If you run lilypond with DYLD_PRINT_LIBRARIES=1 set in the environment does more than one copy of libltdl.7.dylib get loaded? This sounds like a packaging bug to me though, you can probably fix it with use of install_name_tool(1). As for your earlier questions about .so and .dylib - On Mac OS X 10.0 and earlier, there was no way to load MH_DYLIB type files (usually .dylib extensions) at runtime. API was introduced to allow this in 10.1, and dlopen() was added in 10.3, rewritten in 10.4 and dlclose() actually removes the image in 10.5, prior to that only files of MH_BUNDLE type could be unloaded. 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. So, long story short, ltld looks for ".so" because that is the extension used for loadable modules. Guile wants to use its loadable modules as input to ld, this is not portable to ancient Mac OS X, nor ancient Net BSD, and possibly other systems, however it seems unlikly to be a major issue. I think that covers most of the thread, but I admit to now reading all of it. Peter -- Peter O'Gorman http://pogma.com