Hi there,
I have just started playing with GNU Prolog's foreign language interface (among other things, I am trying to write a GNU Prolog interface for the Parma Polyhedra Library, http://www.cs.unipr.it/ppl/).
One of the difficulties I have encountered is with the gplc command: while it allows to specify extra options for the linker (with -L), these options are passed as the first ones in the link command. This would seem to imply that there is no way to link with your own libraries (in addition to the ones needed by GNU Prolog itself). In fact, a command like
gplc -o EXENAME some.pl some.o -L '-Lmylibdir -lmylib'
results in a link command of the form
gcc -Lmylibdir -lmylib ...
and this is such that the library `libmylib' is simply disregarded. Is there a workaround for this? I would like very much to avoid
1) including the entire library in my executable when I need only a part of it; 2) having to specify the complete path of libraries (I would like the linker to look for them in the appropriate places); 3) linking manually, thus having to guess which library are needed by GNU Prolog itself.
Am I imposing an unsatisfiable set of constraints? Thanks a lot
Roberto
users-prolog-admin@gnu.org wrote:
Hi there,
I have just started playing with GNU Prolog's foreign language interface (among other things, I am trying to write a GNU Prolog interface for the Parma Polyhedra Library, http://www.cs.unipr.it/ppl/).
One of the difficulties I have encountered is with the gplc command: while it allows to specify extra options for the linker (with -L), these options are passed as the first ones in the link command. This would seem to imply that there is no way to link with your own libraries (in addition to the ones needed by GNU Prolog itself). In fact, a command like
gplc -o EXENAME some.pl some.o -L '-Lmylibdir -lmylib'results in a link command of the form
gcc -Lmylibdir -lmylib ...and this is such that the library `libmylib' is simply disregarded. Is there a workaround for this? I would like very much to avoid
- including the entire library in my executable when I need only a part of it;
- having to specify the complete path of libraries (I would like the linker to look for them in the appropriate places);
- linking manually, thus having to guess which library are needed by GNU Prolog itself.
Am I imposing an unsatisfiable set of constraints? Thanks a lot
Roberto
I had to do many tricks for linking a program of mine, as it uses C++ and i wanted it to be under automake/autoconf. The only solution i found was to do a gplc -v <file> To have the order of linking done by gplc.
And i just copy&paste this linking directive, and added the things that were required by my application.
PS: all prolog mapped function must be linked between "obj_begin.o" and "obj_end.o" PPS: if anybody has a trick to dynamically register the predicate from C, i'm interested. This would allows me to have Prolog compiled in a shared library module, that i could load and unload when needed.
Hello Roberto,
I have fixed this problem recently because it was really problematic. It is fixed in 1.2.10 which you can find in the unstable directory: ftp://ftp.inria.fr/INRIA/Projects/contraintes/gprolog/unstable/gprolog-1.2.10.tar.gz (a RPM is also available - compiled under RedHat 7.2)
So something like: gplc -o EXENAME some.pl some.o -L '-Lmylibdir -lmylib' should work now...
Roberto Bagnara wrote:
Hi there,
I have just started playing with GNU Prolog's foreign language interface (among other things, I am trying to write a GNU Prolog interface for the Parma Polyhedra Library, http://www.cs.unipr.it/ppl/).
One of the difficulties I have encountered is with the gplc command: while it allows to specify extra options for the linker (with -L), these options are passed as the first ones in the link command. This would seem to imply that there is no way to link with your own libraries (in addition to the ones needed by GNU Prolog itself). In fact, a command like
gplc -o EXENAME some.pl some.o -L '-Lmylibdir -lmylib'results in a link command of the form
gcc -Lmylibdir -lmylib ...and this is such that the library `libmylib' is simply disregarded. Is there a workaround for this? I would like very much to avoid
- including the entire library in my executable when I need only a part of it;
- having to specify the complete path of libraries (I would like the linker to look for them in the appropriate places);
- linking manually, thus having to guess which library are needed by GNU Prolog itself.
Am I imposing an unsatisfiable set of constraints? 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
Users-prolog mailing list Users-prolog@gnu.org http://mail.gnu.org/mailman/listinfo/users-prolog
Daniel Diaz wrote:
Hello Roberto,
I have fixed this problem recently because it was really problematic. It is fixed in 1.2.10 which you can find in the unstable directory: ftp://ftp.inria.fr/INRIA/Projects/contraintes/gprolog/unstable/gprolog-1.2.10.tar.gz (a RPM is also available - compiled under RedHat 7.2)
So something like: gplc -o EXENAME some.pl some.o -L '-Lmylibdir -lmylib' should work now...
Thanks Daniel. It works indeed: I am now able to produce a working GNU Prolog engine statically linked with our library. There is something strange however: the _standard_ `gprolog' executable created by configure, make, make install dies with a segmentation fault. Here is what happens:
$ gdb /usr/local/bin/gprolog GNU gdb Red Hat Linux (5.1-1) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) r Starting program: /usr/local/bin/gprolog
Fatal Error: Memory allocation fault (malloc) in top_level.c:90
Program exited with code 01. (gdb)
I know 1.2.10 is of the unstable kind, but I though you would like to know. I have compiled it with
$ gcc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs Configured with: ../gcc-3.0.3/configure --prefix=/usr/local Thread model: single gcc version 3.0.3
and my machine is a RedHat 7.2 GNU/Linux system. All the best
Roberto
It seems GNU Prolog has some problem to be compiled with gcc 3.0.3. I have to check this (I use 2.96). Maybe you can try the configure with:
./configure --disable-ebp --disable-regs
I think the problems comes from the use of a machine register. These option prevent their use. If you try it I'd like to have your feedback.
Thank you
Roberto Bagnara wrote:
Daniel Diaz wrote:
Hello Roberto,
I have fixed this problem recently because it was really problematic. It is fixed in 1.2.10 which you can find in the unstable directory: ftp://ftp.inria.fr/INRIA/Projects/contraintes/gprolog/unstable/gprolog-1.2.10.tar.gz (a RPM is also available - compiled under RedHat 7.2)
So something like: gplc -o EXENAME some.pl some.o -L '-Lmylibdir -lmylib' should work now...
Thanks Daniel. It works indeed: I am now able to produce a working GNU Prolog engine statically linked with our library. There is something strange however: the _standard_ `gprolog' executable created by configure, make, make install dies with a segmentation fault. Here is what happens:
$ gdb /usr/local/bin/gprolog GNU gdb Red Hat Linux (5.1-1) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) r Starting program: /usr/local/bin/gprolog
Fatal Error: Memory allocation fault (malloc) in top_level.c:90
Program exited with code 01. (gdb)
I know 1.2.10 is of the unstable kind, but I though you would like to know. I have compiled it with
$ gcc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs Configured with: ../gcc-3.0.3/configure --prefix=/usr/local Thread model: single gcc version 3.0.3
and my machine is a RedHat 7.2 GNU/Linux system. All the best
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
Daniel Diaz wrote:
It seems GNU Prolog has some problem to be compiled with gcc 3.0.3. I have to check this (I use 2.96). Maybe you can try the configure with:
./configure --disable-ebp --disable-regs
I think the problems comes from the use of a machine register. These option prevent their use. If you try it I'd like to have your feedback.
Yes, that cured the problem: now everything seems to work. Thanks a lot
Roberto
participants (3)
-
Daniel Diaz -
FORT David -
Roberto Bagnara