On 3 Mar 2011, at 00:03, Ludovic Courtès wrote: >>>> scheme@(guile-user)> (define libm (dynamic-link "/usr/lib/libm.dylib")) >>>> ERROR: In procedure dynamic-link: file: "/usr/lib/libm.dylib", >>>> message: "file not found" >>> >>> You should omit the extension, which will be automatically inferred by >>> Guile (actually ltdl) depending on the system: >>> >>> (dynamic-link "/usr/lib/libm") >>> >>> or: >>> >>> (dynamic-link "libm") >> >> None of those work - I checked and rechecked that. Making a soft link ending >> on ".so", and it works fine. I have seen this before in the Bessel function >> example. > > Right. There’s this insightful test started by you last year: > > http://lists.gnu.org/archive/html/bug-libtool/2010-02/msg00000.html > > The crux is that on older MacOS X versions ‘.dylib’ are shared libraries > (not dlopenable), whereas ‘.so’ are “bundles” (dlopenable). That’s why > lt_dlopenext (which is what ‘dynamic-link’ uses) doesn’t try to open > ‘.dylib’ files.
The shared libraries (not dynamically loadable, except as when starting up the program like some web browser plugins) were on the PPC platform (XCOFF and PEF I think it was). Now (Mac OS 10.5 and later), all is loadable. Haven't seen any .so files, except as coming from GNU/Linux. > May I recommend switching to GNU/Linux? :-) You can always try:-), but Mac OS X 10.5 Intel and later is certified UNIX, and the only parts in the UNIX standard recognizing file name extensions is 'make' and ".c" (I checked on the standardization list). Hans