Loading the SWI-Prolog interface of the PPL under Mac OS X
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').
do? Thanks a lot,
Roberto
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
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
Hi Roberto,
here are my very latest (this week) adventures: - I've downloaded Xcode 2.5 - GMP 4.2.2 compiled: make, make check, make install succeeded
Wrt PPL: - I've tried the CVS version but autoreconf failed - I've tried PPL 0.9, which did not believe I was running GMP 4.2.2 ...
So now I'm using Linux under Parallels Desktop on my Mac OS X.
Ciao, Fred
Le 6 oct. 07 à 19:56, Roberto Bagnara a écrit :
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').
do? Thanks a lot,
Roberto
-- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it
Fred Mesnard wrote:
Wrt PPL:
- I've tried the CVS version but autoreconf failed
Hi Fred,
can you please post a log of the failed autoreconf.
- I've tried PPL 0.9, which did not believe I was running
GMP 4.2.2 ...
Same for this one? Thanks,
Roberto
Le 7 oct. 07 à 17:43, Roberto Bagnara a écrit :
Fred Mesnard wrote:
Wrt PPL:
- I've tried the CVS version but autoreconf failed
can you please post a log of the failed autoreconf.
PPL, CVS version:
% autoreconf configure.ac:291: error: possibly undefined macro: AC_LIBTOOL_DLOPEN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:292: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:293: error: possibly undefined macro: AC_PROG_LIBTOOL autoreconf: /usr/local/bin/autoconf failed with exit status: 1
- I've tried PPL 0.9, which did not believe I was running
GMP 4.2.2 ...
Same for this one?
No, this one has a configure, so let's run it:
... checking for ld used by GCC... /usr/libexec/gcc/i686-apple- darwin8/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld) is GNU ld... no checking for shared library run path origin... done checking how to link with libgmp... -L/usr/local/lib -lgmp checking how to link with libgmpxx... -L/usr/local/lib -lgmpxx -L/usr/ local/lib -lgmp checking for the GMP library version 4.1.3 or above... no configure: error: Cannot find GMP version 4.1.3 or higher. GMP is the GNU Multi-Precision library: see http://www.swox.com/gmp/ for more information. When compiling the GMP library, do not forget to enable the C++ interface: add --enable-cxx to the configuration options.
Although I did compile (make, make check and make install) GMP 4.2.2 yesterday :
/usr/local/lib fred$ ls -la *gmp* -rwxr-xr-x 1 root wheel 273331 Oct 6 08:09 libgmp.3.4.2.dylib lrwxr-xr-x 1 root wheel 18 Oct 6 08:09 libgmp.3.dylib -> libgmp.3.4.2.dylib -rw-r--r-- 1 root wheel 513840 Oct 6 08:09 libgmp.a lrwxr-xr-x 1 root wheel 18 Oct 6 08:09 libgmp.dylib -> libgmp.3.4.2.dylib -rwxr-xr-x 1 root wheel 797 Oct 6 08:09 libgmp.la -rwxr-xr-x 1 root wheel 25971 Oct 6 08:09 libgmpxx.4.0.2.dylib lrwxr-xr-x 1 root wheel 20 Oct 6 08:09 libgmpxx.4.dylib -> libgmpxx.4.0.2.dylib -rw-r--r-- 1 root wheel 32536 Oct 6 08:09 libgmpxx.a lrwxr-xr-x 1 root wheel 20 Oct 6 08:09 libgmpxx.dylib -> libgmpxx.4.0.2.dylib -rwxr-xr-x 1 root wheel 836 Oct 6 08:09 libgmpxx.la
What did I miss?
Fred
Fred Mesnard wrote:
Le 7 oct. 07 à 17:43, Roberto Bagnara a écrit :
Fred Mesnard wrote:
Wrt PPL:
- I've tried the CVS version but autoreconf failed
can you please post a log of the failed autoreconf.
PPL, CVS version:
% autoreconf configure.ac:291: error: possibly undefined macro: AC_LIBTOOL_DLOPEN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:292: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:293: error: possibly undefined macro: AC_PROG_LIBTOOL autoreconf: /usr/local/bin/autoconf failed with exit status: 1
You don't have Libtool installed.
- I've tried PPL 0.9, which did not believe I was running
GMP 4.2.2 ...
Same for this one?
No, this one has a configure, so let's run it:
... checking for ld used by GCC... /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld) is GNU ld... no checking for shared library run path origin... done checking how to link with libgmp... -L/usr/local/lib -lgmp checking how to link with libgmpxx... -L/usr/local/lib -lgmpxx -L/usr/local/lib -lgmp checking for the GMP library version 4.1.3 or above... no configure: error: Cannot find GMP version 4.1.3 or higher. GMP is the GNU Multi-Precision library: see http://www.swox.com/gmp/ for more information. When compiling the GMP library, do not forget to enable the C++ interface: add --enable-cxx to the configuration options.
Although I did compile (make, make check and make install) GMP 4.2.2 yesterday :
/usr/local/lib fred$ ls -la *gmp* -rwxr-xr-x 1 root wheel 273331 Oct 6 08:09 libgmp.3.4.2.dylib lrwxr-xr-x 1 root wheel 18 Oct 6 08:09 libgmp.3.dylib -> libgmp.3.4.2.dylib -rw-r--r-- 1 root wheel 513840 Oct 6 08:09 libgmp.a lrwxr-xr-x 1 root wheel 18 Oct 6 08:09 libgmp.dylib -> libgmp.3.4.2.dylib -rwxr-xr-x 1 root wheel 797 Oct 6 08:09 libgmp.la -rwxr-xr-x 1 root wheel 25971 Oct 6 08:09 libgmpxx.4.0.2.dylib lrwxr-xr-x 1 root wheel 20 Oct 6 08:09 libgmpxx.4.dylib -> libgmpxx.4.0.2.dylib -rw-r--r-- 1 root wheel 32536 Oct 6 08:09 libgmpxx.a lrwxr-xr-x 1 root wheel 20 Oct 6 08:09 libgmpxx.dylib -> libgmpxx.4.0.2.dylib -rwxr-xr-x 1 root wheel 836 Oct 6 08:09 libgmpxx.la
What did I miss?
Your compiler is not searching GMP in /usr/local. You should add
--with-libgmpxx-prefix=/usr/local
to your configure options. Cheers,
Roberto
Le 7 oct. 07 à 19:00, Roberto Bagnara a écrit :
You don't have Libtool installed.
there's one:
$ which libtool /usr/bin/libtool
maybe not the right one!
Your compiler is not searching GMP in /usr/local. You should add
--with-libgmpxx-prefix=/usr/localto your configure options.
ordinateur-de-fred-mesnard:~/Desktop/ppl-0.9 fred$ ./configure --with- libgmpxx-prefix=/usr/local checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes
...
checking for uint_fast64_t... yes checking for ld used by GCC... /usr/libexec/gcc/i686-apple- darwin8/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld) is GNU ld... no checking for shared library run path origin... done checking how to link with libgmp... -L/usr/local/lib -lgmp checking how to link with libgmpxx... -L/usr/local/lib -lgmpxx -L/usr/ local/lib -lgmp checking for the GMP library version 4.1.3 or above... no configure: error: Cannot find GMP version 4.1.3 or higher. GMP is the GNU Multi-Precision library: see http://www.swox.com/gmp/ for more information. When compiling the GMP library, do not forget to enable the C++ interface: add --enable-cxx to the configuration options. ordinateur-de-fred-mesnard:~/Desktop/ppl-0.9 fred$
Fred Mesnard wrote:
Le 7 oct. 07 à 19:00, Roberto Bagnara a écrit :
You don't have Libtool installed.
there's one:
$ which libtool /usr/bin/libtool
maybe not the right one!
The command `libtool --version' should report at least version 1.5.22.
Your compiler is not searching GMP in /usr/local. You should add
--with-libgmpxx-prefix=/usr/localto your configure options.
ordinateur-de-fred-mesnard:~/Desktop/ppl-0.9 fred$ ./configure --with-libgmpxx-prefix=/usr/local checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes
...
checking for uint_fast64_t... yes checking for ld used by GCC... /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld) is GNU ld... no checking for shared library run path origin... done checking how to link with libgmp... -L/usr/local/lib -lgmp checking how to link with libgmpxx... -L/usr/local/lib -lgmpxx -L/usr/local/lib -lgmp checking for the GMP library version 4.1.3 or above... no configure: error: Cannot find GMP version 4.1.3 or higher. GMP is the GNU Multi-Precision library: see http://www.swox.com/gmp/ for more information. When compiling the GMP library, do not forget to enable the C++ interface: add --enable-cxx to the configuration options. ordinateur-de-fred-mesnard:~/Desktop/ppl-0.9 fred$
Please send me the generated `config.log' file.
Hi there!
Enrico: thank you for your input, I've only installed the latest Xcode!
Roberto:
Le 7 oct. 07 à 19:28, Roberto Bagnara a écrit :
The command `libtool --version' should report at least version 1.5.22.
% libtool --version libtool: unknown option character `-' in: --version
Please send me the generated `config.log' file.
Attached
Ciao, Fred
Fred Mesnard wrote:
Roberto:
Le 7 oct. 07 à 19:28, Roberto Bagnara a écrit :
The command `libtool --version' should report at least version 1.5.22.
% libtool --version libtool: unknown option character `-' in: --version
ROTFL: this is not the real thing. The real libtool would do something like:
$ libtool --version ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Is this all you can obtain from that `libtool' command? Doesn't it have a -h option?
Please send me the generated `config.log' file.
Attached
It looks like you have more than one versions of GMP installed on your system and they conflict with one another. Get rid of all of them but one. Cheers,
Roberto
Le 8 oct. 07 à 09:50, Roberto Bagnara a écrit :
Fred Mesnard wrote:
Roberto: Le 7 oct. 07 à 19:28, Roberto Bagnara a écrit :
The command `libtool --version' should report at least version 1.5.22.
% libtool --version libtool: unknown option character `-' in: --version
ROTFL: this is not the real thing. The real libtool would do something like:
$ libtool --version ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Is this all you can obtain from that `libtool' command? Doesn't it have a -h option?
% libtool -h libtool: unknown option character `h' in: -h
!!!
Please send me the generated `config.log' file.
Attached
It looks like you have more than one versions of GMP installed on your system and they conflict with one another. Get rid of all of them but one.
thank you Roberto. I propose we forget my own Mac for now.
Ciao, Fred
On Oct 8, 2007, at 7:50 AM, Roberto Bagnara wrote:
ROTFL: this is not the real thing. The real libtool would do something like:
$ libtool --version ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
It is not the GNU libtool. GNU libtool is installed as glibtool (and libtoolize -> glibtoolize).
$ glibtool --version ltmain.sh (GNU libtool) 1.5.24 (1.1220.2.455 2007/06/24 02:13:29)
Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
However, this is something which needs no manual specification, since the autotools use glibtool when detecting the host platform is MacOS X.
In any case, if automatic recognition does not take place (which is something I never saw occurring) LIBTOOL and LIBTOOLIZE env. variables can be used.
-enrico
Le 8 oct. 07 à 16:26, Enrico Franchi a écrit :
On Oct 8, 2007, at 7:50 AM, Roberto Bagnara wrote:
ROTFL: this is not the real thing. The real libtool would do something like:
$ libtool --version ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
It is not the GNU libtool. GNU libtool is installed as glibtool (and libtoolize -> glibtoolize).
$ glibtool --version ltmain.sh (GNU libtool) 1.5.24 (1.1220.2.455 2007/06/24 02:13:29)
I get:
$ glibtool --version ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58)
Too old!
However, this is something which needs no manual specification, since the autotools use glibtool when detecting the host platform is MacOS X.
In any case, if automatic recognition does not take place (which is something I never saw occurring) LIBTOOL and LIBTOOLIZE env. variables can be used.
Thanks for the hint.
Fred
On Oct 8, 2007, at 5:42 AM, Fred Mesnard wrote:
Hi there!
Enrico: thank you for your input, I've only installed the latest Xcode!
This is very strange. In one of your past messages autoreconf says:
% autoreconf configure.ac:291: error: possibly undefined macro: AC_LIBTOOL_DLOPEN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:292: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:293: error: possibly undefined macro: AC_PROG_LIBTOOL
autoreconf: /usr/local/bin/autoconf failed with exit status: 1 ^^^^^^^^^^^^^^^^^^^^^^^
That is to say you are running an autoconf installed in /usr/*local*/ bin/autoconf.
However, XCode does not install autoconf (or automake) in /usr/local, but in /usr. You have either heavily customized the XCode installation stage or you *did* install an additional autoconf. I'm not even sure you can tell XCode to install stuff in /usr/local without manually editing the installation scripts contained in the .pkg.
Moreover, that error is absolutely typical of configurations with multiple autotools installed. I had that very same error and fixed it as I suggested.
-enrico
On Oct 7, 2007, at 4:34 PM, Fred Mesnard wrote:
% autoreconf configure.ac:291: error: possibly undefined macro: AC_LIBTOOL_DLOPEN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:292: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:293: error: possibly undefined macro: AC_PROG_LIBTOOL autoreconf: /usr/local/bin/autoconf failed with exit status: 1
I had similar problems, and I have solved them adding a couple of symbolic links (unfortunately, I don't remember exactly which ones).
I suppose you installed newer versions of autoconf and automake, while you did not update libtool itself. The newer auto* look for macros in a different directory. You may fix the problem using --include options or symlinking the macros.
One more option is to symlink
ln -s /usr/share/autoconf/autoconf/autoconf.m4 /usr/local/share/ autoconf/autoconf/autoconf.m4
(assuming you installed autoconf in /usr/local/bin); additional symlinks may be required. Probably adding the
--include /usr/share/autoconf/autoconf/
should be tried first since it is not a 'modification'. Options -ivf for autoreconf may also be useful.
-enrico
participants (4)
-
Enrico Franchi -
Fred Mesnard -
Fred Mesnard -
Roberto Bagnara