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: Tue, 2 Feb 2010 16:48:23 +0100 Message-ID: <675379A5-A6C5-4331-B82B-1E1F975C359A@math.su.se> References: <20100202064208.GC5651@gmx.de> <657AF3C8-764A-4DDE-918F-F1D97DA8E8EC@math.su.se> <359C630D-FEA1-4422-91B5-6FB0DFD6941D@raeburn.org> 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 1265125802 19122 80.91.229.12 (2 Feb 2010 15:50:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Feb 2010 15:50:02 +0000 (UTC) Cc: bug-guile@gnu.org, bug-libtool@gnu.org To: Ken Raeburn Original-X-From: bug-libtool-bounces+gnu-bug-libtool=m.gmane.org@gnu.org Tue Feb 02 16:49:58 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 1NcL0V-0000yY-Sr for gnu-bug-libtool@m.gmane.org; Tue, 02 Feb 2010 16:49:55 +0100 Original-Received: from localhost ([127.0.0.1]:53153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcL0O-0005sL-II for gnu-bug-libtool@m.gmane.org; Tue, 02 Feb 2010 10:49:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NcKzQ-0005JG-MJ for bug-libtool@gnu.org; Tue, 02 Feb 2010 10:48:32 -0500 Original-Received: from [199.232.76.173] (port=52958 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcKzQ-0005Ik-8Y for bug-libtool@gnu.org; Tue, 02 Feb 2010 10:48:32 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NcKzO-0001uQ-8s for bug-libtool@gnu.org; Tue, 02 Feb 2010 10:48:32 -0500 Original-Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]:43355) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NcKzL-0001tl-Pv; Tue, 02 Feb 2010 10:48:27 -0500 Original-Received: from h131n2-fre-d2.ias.bredband.telia.com (78.72.157.131) by pne-smtpout2-sn1.fre.skanova.net (7.3.140.3) (authenticated as u26619134) id 4B5C67720013E1DB; Tue, 2 Feb 2010 16:48:24 +0100 In-Reply-To: <359C630D-FEA1-4422-91B5-6FB0DFD6941D@raeburn.org> 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:7238 gmane.lisp.guile.bugs:4488 Archived-At: On 2 Feb 2010, at 15:20, Ken Raeburn wrote: >>>> On Mac OS X (trying it on 10.5.8 PPC G4), guile-1.8.7 cannot open >>>> dynamic library files with name extensions .dylib, but only if they >>>> are renamed using .so instead. On the Bug-Guile list they say it >>>> just calls libltdl, in the libtool package. I have installed latest >>>> of both, but the problem persists: >>> >>> libtool should produce modules named *.so on Darwin if you pass the >>> -module flag at link time. Typically, -avoid-version is used for >>> modules as well. >> >> But dlopen() on Mac OS X can only open files in the native format, >> which isn't ELF, and they are typically named with the .dylib file >> name extension. If it finds a .so file on ELF format, all it does >> is reporting it cannot be opened. > > ".so" doesn't mean ELF format, and on some systems including Mac OS > X, "dynamically linked shared library" (e.g., a ".dylib" file) is > not the same as "dynamically loadable object". Did you not see my > earlier email to you and the bug-guile list? The fact is that currently Guile, which relies on libtool, cannot open .dylib files, though it works perfectly if they are renamed .so. As for what filenames to use, dlopen() does not care - it is something imposed by libtool. Also, all new native DLLs (see below) on Mac OS X are named .dylib. I have only seen .bundle that are directories, also are called "plugins". 'man dlopen' says: dlopen -- load and link a dynamic library or bundle but does not specify what happens if one tries to open a bundle directory. Looking at an Internet Plug-In, I can do: file '/Library/Internet Plug-Ins/DRM Plugin.bundle/Contents/MacOS/ DRM Plugin' /Library/Internet Plug-Ins/DRM Plugin.bundle/Contents/MacOS/DRM Plugin: header for PowerPC PEF executable (PEF is the old format used on Mac OS 9 PPC.) So if one opens this file directly, it has no filename extension at all. So I suggested on the Bug-Guile list having an opening sequence, say trying: the full name, .dylib, and .so. If you think of .so as a general POSIX standard not tied to ELF, that is of course OK. Hans