I am having a problem with `plld' on one machine. The problem is there I get undefined references to symbols of the readline library, which is installed in the system:
$ plld -cc gcc -c++ g++ -ld g++ -o ppl_pl ppl_swiprolog.o ppl_pl.o \ -L../../../src/.libs -lppl \ -L../../../Watchdog/src/.libs -lpwl \ -lm -lgmpxx -lgmp /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x33): In function `PL_install_readline': pl-rl.c: undefined reference to `rl_readline_name' /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x3d):pl-rl.c: undefined reference to `rl_attempted_completion_function' /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x47):pl-rl.c: undefined reference to `rl_basic_word_break_characters' ...
If I add an explicit "-lreadline", then linking succeeds:
$ plld -cc gcc -c++ g++ -ld g++ -o ppl_pl ppl_swiprolog.o ppl_pl.o \ -L../../../src/.libs -lppl \ -L../../../Watchdog/src/.libs -lpwl \ -lm -lgmpxx -lgmp -lreadline % halt
The problem seems to be here:
$ pl -dump-runtime-variables CC="gcc"; PLBASE="/usr/lib/pl-5.4.7"; PLARCH="i686-linux"; PLLIBS="-ldl /usr/lib/libreadline.a -lncurses -lncurses -lm -lrt "; PLLIB="-lpl"; PLLDFLAGS="-export-dynamic -O3 -pthread"; PLSOEXT="so"; PLVERSION="50407"; PLSHARED="yes"; PLTHREADS="yes";
I have no idea why we have "/usr/lib/libreadline.a" instead of "-lreadline" in `PLLIBS'. In fact we get:
$ plld -v -cc gcc -c++ g++ -ld g++ -o ppl_pl ppl_swiprolog.o ppl_pl.o -L../../../src/.libs -lppl -L../../../Watchdog/src/.libs -lpwl -lm -lgmpxx -lgmp eval `pl -dump-runtime-variables` CC="gcc" PLBASE="/usr/lib/pl-5.4.7" PLARCH="i686-linux" PLLIBS="-ldl /usr/lib/libreadline.a -lncurses -lncurses -lm -lrt" PLLIB="-lpl" PLLDFLAGS="-export-dynamic -O3 -pthread" PLSOEXT="so" PLTHREADS="yes" g++ -o ppl_pl -export-dynamic -O3 -pthread ppl_swiprolog.o ppl_pl.o /usr/lib/libreadline.a -L/usr/lib/pl-5.4.7/lib/i686-linux -L../../../src/.libs -L../../../Watchdog/src/.libs -lpl -lppl -lpwl -lm -lgmpxx -lgmp -ldl -lncurses -lncurses -lm -lrt /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x33): In function `PL_install_readline': pl-rl.c: undefined reference to `rl_readline_name' /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x3d):pl-rl.c: undefined reference to `rl_attempted_completion_function' /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x47):pl-rl.c: undefined reference to `rl_basic_word_break_characters' ...
So, either "-lreadline" should be used instead of "/usr/lib/libreadline.a", or "/usr/lib/libreadline.a" should be put after "-lpl" in the link command. In both cases, this would seem to be a bug in SWI-Prolog 5.4.7. All the best,
Roberto
On Friday 04 November 2005 21:04, Roberto Bagnara wrote:
I am having a problem with `plld' on one machine. The problem is there I get undefined references to symbols of the readline library, which is installed in the system:
$ plld -cc gcc -c++ g++ -ld g++ -o ppl_pl ppl_swiprolog.o ppl_pl.o \ -L../../../src/.libs -lppl \ -L../../../Watchdog/src/.libs -lpwl \ -lm -lgmpxx -lgmp /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x33): In function `PL_install_readline': pl-rl.c: undefined reference to `rl_readline_name' /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x3d):pl-rl.c: undefined reference to `rl_attempted_completion_function' /usr/lib/pl-5.4.7/lib/i686-linux/libpl.a(pl-rl.o)(.text+0x47):pl-rl.c: undefined reference to `rl_basic_word_break_characters' ...
If I add an explicit "-lreadline", then linking succeeds:
$ plld -cc gcc -c++ g++ -ld g++ -o ppl_pl ppl_swiprolog.o ppl_pl.o \ -L../../../src/.libs -lppl \ -L../../../Watchdog/src/.libs -lpwl \ -lm -lgmpxx -lgmp -lreadline % halt
The problem seems to be here:
$ pl -dump-runtime-variables CC="gcc"; PLBASE="/usr/lib/pl-5.4.7"; PLARCH="i686-linux"; PLLIBS="-ldl /usr/lib/libreadline.a -lncurses -lncurses -lm -lrt "; PLLIB="-lpl"; PLLDFLAGS="-export-dynamic -O3 -pthread"; PLSOEXT="so"; PLVERSION="50407"; PLSHARED="yes"; PLTHREADS="yes";
I have no idea why we have "/usr/lib/libreadline.a" instead of "-lreadline" in `PLLIBS'. In fact we get:
Because the RPM is built using the static version of libreadline to avoid compatibility problems that were involved with this library for a long time. Maybe these are sufficiently resolved to use the shared object again these days. I'm not sure. If you build Prolog yourself from the sources there should be no problem.
So, either "-lreadline" should be used instead of "/usr/lib/libreadline.a", or "/usr/lib/libreadline.a" should be put after "-lpl" in the link command. In both cases, this would seem to be a bug in SWI-Prolog 5.4.7.
I modified plld to order .a files under the libraries rather than with the object files. This is only for the 5.5.x series. For the 5.4.x series I suggest adding -lreadline to the options.
Cheers --- Jan
P.s. It may be wise to consider turning the ppl extension into a library that is dynamically loaded in SWI-Prolog. No more need to recompile it for each new version of SWI-Prolog, easier to combine with other packages.
Jan Wielemaker wrote:
On Friday 04 November 2005 21:04, Roberto Bagnara wrote:
I have no idea why we have "/usr/lib/libreadline.a" instead of "-lreadline" in `PLLIBS'. In fact we get:
Because the RPM is built using the static version of libreadline to avoid compatibility problems that were involved with this library for a long time. Maybe these are sufficiently resolved to use the shared object again these days. I'm not sure. If you build Prolog yourself from the sources there should be no problem.
So, either "-lreadline" should be used instead of "/usr/lib/libreadline.a", or "/usr/lib/libreadline.a" should be put after "-lpl" in the link command. In both cases, this would seem to be a bug in SWI-Prolog 5.4.7.
I modified plld to order .a files under the libraries rather than with the object files. This is only for the 5.5.x series. For the 5.4.x series I suggest adding -lreadline to the options.
Thanks for the diagnosis and for the suggestion, Jan.
P.s. It may be wise to consider turning the ppl extension into a library that is dynamically loaded in SWI-Prolog. No more need to recompile it for each new version of SWI-Prolog, easier to combine with other packages.
It sounds very interesting: how can we do that? Cheers,
Roberto
On Friday 04 November 2005 22:10, Roberto Bagnara wrote:
P.s. It may be wise to consider turning the ppl extension into a library that is dynamically loaded in SWI-Prolog. No more need to recompile it for each new version of SWI-Prolog, easier to combine with other packages.
It sounds very interesting: how can we do that?
Not really knowing what ppl does (well, looked at the website for 5 minutes) and what role Prolog is playing in the picture, the general idea of combining Prolog with some library is that the library provides predicates for Prolog and possibly makes calls to Prolog. Then there is a `main' program, that either has to be Prolog or the thing you link to. The latter is an option if the external thing is by nature interactive, but in general you want the interactive Prolog shell to be the main routine. As XPCE shows, SWI-Prolog even allows access to the interactive toplevel for X11 and Windows GUI applications, although this complicates the issues a bit. Finally there is the issue of initialisation.
Normally, try to compile the thing you want to add to Prolog into a shared object/dll, for now named mylib.so. You create this using "plld -shared mylib ..." Make sure this library exports a C-function install_mylib() that calls whatever you need to do to register predicates and initialise the library. Then write mylib.pl stating
:- module(mylib, [ foo/1, bar/2, ... ]). :- initialization load_foreign_library(foreign(mylib)).
and make sure mylib.so is found on the search path foreign.
Normally, there should only be minor changes to the actual code linking the systems and the Makefile compared to your current embedding approach.
Cheers --- Jan
participants (2)
-
Jan Wielemaker -
Roberto Bagnara