[PPL-devel] Loading the SWI-Prolog interface of the PPL under Mac OS X

[Roberto Bagnara]

Enrico Franchi wrote:
> 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).

I think your analysis is correct.  The problem is now understanding
what are we doing wrong.  I mean, in interfaces/Prolog/SWI/Makefile.am
we say

pkglib_LTLIBRARIES = libppl_swiprolog.la
nodist_libppl_swiprolog_la_SOURCES = ppl_swiprolog.cc
libppl_swiprolog_la_LIBADD = \
$(top_builddir)/src/libppl.la \
$(WATCHDOG_LIBRARY) \
@extra_libraries@
libppl_swiprolog_la_LDFLAGS = -module -avoid-version

Nowhere do we say that the extension has to be .so.  I would expect
the Autotools (Autoconf, Automake and Libtool) to take care of this,
but apparently they do not.  Any idea why?  Do you find the string
"dylib" in the `libtool' file that you find in the build directory
just after invoking `configure'?  Do you find it in
interfaces/Prolog/SWI/Makefile?
Thanks,

     Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it