On Oct 6, 2007, at 5:56 PM, Roberto Bagnara wrote:
Dear Mac OS X users of the PPL,
in view of the imminent release of PPL 0.10 we are going through the TODO file. One item I added some time ago to that file says:
- In the SWI-Prolog documentation, the command to dynamically load the library has to be modified so as to specify the `.so' extension: this is required under Mac OS X and seems not to do any harm under GNU/Linux.
Can you please confirm that
?- load_foreign_library('/usr/local/lib/ppl/libppl_swiprolog').
and
?- unload_foreign_library('/usr/local/lib/ppl/libppl_swiprolog').
do not work under Mac OS X, while
?- load_foreign_library('/usr/local/lib/ppl/libppl_swiprolog.so'). ?- unload_foreign_library('/usr/local/lib/ppl/libppl_swiprolog.so').
In my opinion, the problem is another one.
The predicate load_foreign_language/1 uses absolute_file_name/3 to determine the exact name of the library to load and loads it. absolute_file_name determines the full file name using standard extensions of the host platform. Under Linux it is .so, under MacOS X it is .dylib
However, the ppl build/installation script creates the library with the .so extension even on OS X. So if we call load_foreign_language without specifying the extension, the prolog system tries to load a *.dylib named file, but the file ends with .so.
If the library was installed with the .dylib terminated name, it would work without specifying the extension. For instance, I created a symbolic link
$ sudo ln -s /opt/local/lib/ppl/libppl_swiprolog.so /opt/local/lib/ ppl/libppl_swiprolog.dylib
then:
$ swipl % /Users/riko/.plrc compiled 0.00 sec, 264 bytes Welcome to SWI-Prolog (Multi-threaded, Version 5.6.39) Copyright (c) 1990-2007 University of Amsterdam. SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Please visit http://www.swi-prolog.org for details.
For help, use ?- help(Topic). or ?- apropos(Word).
1 ?- load_foreign_library('/opt/local/lib/ppl/libppl_swiprolog'). Yes
(I have everything in /opt/... but the method works the same for /usr/)
In my opinion the configuration scripts should try to use the correct extension for dynamic libraries on MacOS X. Of course, this is not an error, since OS X itselef does not rely on extensions. However, other programs (e.g., swiprolog) may do wrong assumptions on them, so it would be preferable to follow conventions.
P.S. Loading the library with the full name (comprising the extension) works on Linux because that is the 'real' name of the library. However, it may not work in an environment where the library is installed with a different filename (I'm thinking about windows .dll, assuming that the build systems creates libraries with names ending with .dll).
-enrico