Re: Undefined procedure on foreign library in 6.6.4

On 04/03/2014 12:22 PM, jon judge wrote:
> $  readelf -d libtestfo.so | grep NEEDED
>   0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
>   0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>
> $ whereis libswipl.so
> libswipl: /usr/lib/libswipl.so
>
> So libswipl.so exists, and together with SWI-Prolog.h installed as part of
> the package install, I'm able to build the original 'c' code using this lib
> without errors.  ie not a static build with source code. I'm not clear on
> what the swipl-ld then does or needs re:static/dynamic builds.
>
> I'm right at the edge of my knowledge re: c and build stuff here.. as you
> can probably tell. Not sure if the above is relevant or useful.

It starts to become clear.  Debian (and Ubuntu) installs the SWI-Prolog 
shared object in /usr/lib/libswipl.so and the static library in
/usr/lib/swi-prolog/lib/<arch>/libswipl.a.  Now, swipl-ld passes

  -L/usr/lib/swi-prolog/lib/<arch> -lswipl

as parts of it arguments.  That now causes your shared object to be 
linked with the static libswipl.a, which is why it is so big.  For each
SWI-Prolog symbol, we have two versions: one in the running shared 
object and one linked into your shared object.  Without 
-Bfunction-symbols, this does in the end not matter because ELF will 
take the
first symbol, which comes from the running Prolog system.  With this
option however, you link to the function linked in *your* shared
object.  This wouldn't be disastrous, except the the visibility
options passed to GCC ensure that your copy of PL_register_foreign()
also talks to your local copies of the global variables that contain
the Prolog state.

Your simple work-around is to remove libswipl.a from 
/usr/lib/swi-prolog/lib/<arch>.  After that, you nicely link to the 
shared object and all
works just fine (except that you cannot create statically linked
executables that depend on SWI-Prolog anymore).

Now, for Eugeniy and me, the issue is how to deal with this properly.
 From Eugeniy's mail, I get the impression that the situation is already
different for Debian. Is that because Debian does (no longer?) install
libswipl.a?  My guess is that either both the static and dynamic library
must be in the same directory or we should only ship the dynamic one.
Eugeniy?


	Cheers --- Jan

> View this message in context: http://swi-prolog.996271.n3.nabble.com/Undefined-procedure-on-foreign-library-in-6-6-4-tp14676p14696.html
> Sent from the SWI Prolog mailing list archive at Nabble.com.
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>