Re: Runtime exception on Linux: cannot open shared object file: No such file or directory

On 10/16/2013 03:23 AM, Kaitain Jones wrote:
> Using swipl-ld on Ubuntu 12.04 64-bit.
>
> Just compiling, linking and running Jan's very basic example foreign
> language interface code as detailed here:
>
> http://www.swi-prolog.org/pldoc/man?section=plld
>
> I find I have to compile with some extra flags to pull in the libs that
> seem to be necessary for full compilation/linking. Instead of:
>
> swipl-ld -o calc calc.c calc.pl
>
>
> I have to use:
>
> swipl-ld -o calc calc.c calc.pl -lgmp -lrt -lm -lncurses -ldl -lunwind

That should, at least in theory, be done by swipl-ld.  Possibly is was
messed up with all the changes for dealing with MinGW on windows.  Next,
by default libswipl is a dynamic library and that doesn't need all 
these.  Did you force creating a static lib?


> This all seems to compile okay:
>
> % calc.pl compiled 0.00 sec, 2 clauses
> % autoloading prolog_codewalk:must_be/2 from /usr/lib/swi-prolog/library/error
> % autoloading prolog_codewalk:portray_clause/1 from
> /usr/lib/swi-prolog/library/listing
> % autoloading prolog_codewalk:clause_info/4 from
> /usr/lib/swi-prolog/library/prolog_clause
> % autoloading prolog_codewalk:initialization_layout/4 from
> /usr/lib/swi-prolog/library/prolog_clause
> % autoloading error:assertion/1 from /usr/lib/swi-prolog/library/debug
> % autoloading record:member/2 from /usr/lib/swi-prolog/library/lists
> % autoloading prolog_source:directory_file_path/3 from
> /usr/lib/swi-prolog/library/filesex
> % autoloading files_ex:use_foreign_library/2 from
> /usr/lib/swi-prolog/library/shlib
> % autoloading qsave:current_foreign_library/2 from
> /usr/lib/swi-prolog/library/shlib
> % autoloading prolog_debug:backtrace/1 from
> /usr/lib/swi-prolog/library/prolog_stack
> % autoloading oset:reverse/2 from /usr/lib/swi-prolog/library/lists
> % autoloading prolog_codewalk:clause_name/2 from
> /usr/lib/swi-prolog/library/prolog_clause
> % Autoloader: iteration 1 resolved 11 predicates and loaded 12 files
> in 0.048 seconds.  Restarting ...
> % autoloading files_ex:permission_error/3 from /usr/lib/swi-prolog/library/error
> % autoloading files_ex:maplist/2 from /usr/lib/swi-prolog/library/apply
> % Autoloader: loaded 11 files in 2 iterations in 0.075 seconds
> % halt
>
> It actually runs, and the output is as desired. But at the start there's
> always a (seemingly benign) exception/error that gets triggered on
> initialization:
>
>
>> *./calc pi/2**ERROR: /usr/lib/swi-prolog/library/filesex.pl:57: Initialization goal raised exception:
> ERROR: '$open_shared_object'/3: files: cannot open shared object file:
> No such file or directory*
> Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version 6.4.1)
> Copyright (c) 1990-2013 University of Amsterdam, VU 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.5707963267948966
>
>
> I first encountered this while trying to build a much larger project, and
> wondered if I had introduced the issue myself. But I stripped things down
> to Jan's simple example and it's visible there, too. I googled for similar
> problems and saw that other people were having them (albeit with different
> libs) but I couldn't really tell from his responses if Jan was saying that
> this would be a general issue on Linux, or whether it would be expected
> only if you were trying to use specific files:
>
> "You should create a small hierarchy that includes the required
> .so files and makes sure that the file-search-path 'foreign'
> can find these files.  There are many ways to do that."
>
>
> The exception doesn't actually cause any issues with program execution so
> far as I can tell (in either the example program or my program), but I
> never like things I don't fully understand and am wondering if this will
> bite me later. If anyone can shed some light on what's going on I'd be
> grateful.

It seems that autoloading pulls in far too much code these days.  Most
likely that is because the current autoloader is based on the quite 
smart `code walker'.  This library has quite a few dependencies :-(

Ideally, the autoloader should not save itself and its dependencies ...
Yet better, it should only track things that can be reached from the
user's initial goal.  Unfortunately this cannot be done reliably.

The best way might be to ensure that your program pulls in all
dependencies and create the state without using the system autoloader.
That can be done using qsave_program/2, but not using swipl-ld right
now.  Needs some work :-(

Of course, the simplest way is to use #! scripts ...

	Cheers --- Jan