From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.comp.gnu.libtool.bugs,gmane.lisp.guile.bugs Subject: Re: Mac OS X .dylib not working Date: Wed, 3 Feb 2010 09:23:12 -0500 Message-ID: <1E07AEBF-099D-4B17-B2B8-0EE5E85B6397@raeburn.org> 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> <51A25259-AD5F-4D39-9319-C173F424568F@math.su.se> <87iqaftt2r.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1265207017 32665 80.91.229.12 (3 Feb 2010 14:23:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2010 14:23:37 +0000 (UTC) Cc: bug-guile@gnu.org, bug-libtool@gnu.org To: =?iso-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: bug-libtool-bounces+gnu-bug-libtool=m.gmane.org@gnu.org Wed Feb 03 15:23:33 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 1Ncg8i-0003jg-1T for gnu-bug-libtool@m.gmane.org; Wed, 03 Feb 2010 15:23:33 +0100 Original-Received: from localhost ([127.0.0.1]:44027 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ncg8h-0002Pz-B8 for gnu-bug-libtool@m.gmane.org; Wed, 03 Feb 2010 09:23:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ncg8b-0002PK-2E for bug-libtool@gnu.org; Wed, 03 Feb 2010 09:23:25 -0500 Original-Received: from [199.232.76.173] (port=58771 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ncg8a-0002Oz-Kf for bug-libtool@gnu.org; Wed, 03 Feb 2010 09:23:24 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Ncg8Z-0008VH-5m for bug-libtool@gnu.org; Wed, 03 Feb 2010 09:23:24 -0500 Original-Received: from splat.raeburn.org ([69.25.196.39]:45876 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ncg8R-0008Tv-8h; Wed, 03 Feb 2010 09:23:22 -0500 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o13ENCdV000049; Wed, 3 Feb 2010 09:23:12 -0500 (EST) In-Reply-To: <87iqaftt2r.fsf@gnu.org> X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:7242 gmane.lisp.guile.bugs:4493 Archived-At: [Is Hans on one of these lists now? His original message to bug-guile = said not and asked to be cc'ed.] On Feb 2, 2010, at 13:01, Ludovic Court=E8s wrote: > The Guile manually specifically tells that FNAME should not contain an > extension. That could be unfortunate, since it means that unlike other Mac = applications, a Guile application would not be able to customize its = plugin names to use Foo.quuxplugin type names. Guile apps would be = limited to a hardcoded set of suffixes then, right? > Surprisingly, I just noticed that Guile itself doesn=92t use the = =91-module=92 > option of Libtool when creating its =91libguile-srfi-srfi-1=92 module = (which > is meant to be dlopened *or* directly linked against), although this = has > never caused any problems on OS X. If you search for that in [1], > =91libguile-srfi-srfi-1=92 is actually created with =91-dynamiclib=92. Current versions of Mac OS X can load shared libraries (.dylib) as well = as the bundle format that seems to have been the original plugin form = (.so, .bundle, ...). So in practice, assuming you can dlopen and = dlclose a shared library works pretty well, though I gather it might not = have worked as well in earlier releases. But we should also support the = format(s) intended for plugin modules as well, and the naming = conventions (which appear to be somewhat varied, and less consistent = than on other OSes). At least, that's my impression; I'm not an expert in that area of the = OS, I've just read some of the docs... Ken=