Example C program crashes with "cannot open shared object file" #1193
Comments
|
Probably unrelated, but it seems that the wrong compiler is used by but I built with: |
|
Probably requires |
|
It seems that I tried running the individual steps manually, changing the The expected external references were there: |
|
When I copied |
|
Update - it appears to not be anything in the |
|
May well be that the algorithm to find the home dir is disturbed at some place by the stuff that is in the build environment. See docs for the various steps tried to find the resource file. |
|
That seems to be the problem -- when I set the environment variable The problem seems to be that at |
|
After all, the traceback doesn't indicate a crash -- Is the traceback from a different thread than what runs I read the documentation on resources (which doesn't mention the |
|
I tried running Instead, I ran the commands by hand, adding This also got the traceback (to I wonder if this should be debugged using |
|
--no-pce doesn't seem to be necessary as it uses |
|
I see. In both cases the state includes library(ansi_term) which depends on uri_file_name/2 and thus includes library(uri) which depends on the uri.so foreign object. When started outside the Prolog source tree, it still gets the actual installation location and can load the foreign object. When started inside the man dir, using swipl.home in the parent directory of the executable, it thinks the home is the source tree. But now, the foreign object is not in the expected place and thus we cannot find the uri object. Now it is a little unclear what to do. One is to use the foreign(save) option of qsave_program to include uri.so in the saved state. Another is to avoid the dependency on uri_file_name/2 or, probably even better on library(ansi_term). Better control over the dependency is probably the best way to go in the long term. How exactly is non-trivial. Part of the unwanted dependencies consider the support for debugging and interactive behavior. |
|
Pushed a commit to remove the old swipl.home and swipl.rc from the top of the source. These were old remains from the pre-cmake build setup. This makes calc in man work, but does not resolve the issue otherwise. |
|
Is there a way to turn on trace at the beginning of the executable? Anyway, I noticed that I tried this, but it didn't fix the problem (I reinstated swipl.home, swipl.rc so that the bug would be trigered): which expanded to: hmmm ... shouldn't it have called |
|
I tried commenting out |
|
As is, you cannot create a saved state using swipl-ld from the version running in the build directory because it uses It might be.a good idea to change building the state to use Tracing is a bit hard. You can insert |
|
Is the
|
I think so. It is used by the relocatable runtime environments as used for Windows and MacOS to find the home relative to the executable. I seems more elegant then using an environment variable. Environment variables are global. Using this "link" we can find the home from the executable/share object, so we can have multiple installations active. |
|
I suppose I should document Getting back to the original problem, a saved state contains: Length Date Time Name
--------- ---------- ----- ----
124 2023-08-28 17:12 $prolog/options.txt
556753 2023-08-28 17:12 $prolog/state.qlf
31328 2023-08-18 16:56 shlib('x86_64-linux',time)
29640 2023-08-14 17:17 shlib('x86_64-linux',uri)
--------- -------
617845 4 filesThe "verbose" messages from /home/peter/.local/bin/swipl -f none -F none -g true -t 'consult(['\''re.pl'\'']),qsave_program('\''pltmp-28205'\'',[goal=true,toplevel=halt,init_file=none,foreign(save),stand_alone(true),verbose(true)])'
% Disabled autoloading (loaded 36 files)
% autoloading error:assertion/1 from /home/peter/.local/lib/swipl/library/debug
% autoloading prolog_clause:nth1/3 from /home/peter/.local/lib/swipl/library/lists
% Disabled autoloading (loaded 0 files)
% Autoloader: loaded 0 files in 1 iterations in 0.052 seconds
% haltAny suggestions about how to find out why I suppose it doesn't really matter, because if they're needed, they're in the saved state (at least, if |
I think they are included too early by library(ansi_term). URIs are used for smart linking in terminals capable of (non-standard) ANSI sequences to create hyperlinks and timing is used to figure out the fore and background color of the console. Probably we should avoid these to be loaded into an otherwise non-interactive executable or we should move the minimal requirements to the core. It would be nice if pure Prolog executables do not require foreign code in the state. Debugging the stuff that happens really early is a bit hard. Typically I insert write statements where needed. The ultimate way to find why a library is loaded is to add something like this to the library. You may have better results using |
|
How would I use There seem to be 3 places where ansi_term is used:
and ansi_term uses library(uri): uri_file_name/2 I could make the error messages go away (and the inclusions of foreign code for I don't use ansi_term (but I use emacs shell), so this seems fine to me. PS: I couldn't figure out how to increase the amount of backtrace from catch_with_backtrace during init ... setting the |
The problem is the same as using
That is more or less what I expected. The -c entry point ( IMO, loading library(ansi_term) is in itself ok. Terminal apps may want to use it anyway. You can avoid loading it by ensuring stdin, stdout or stderr is not connected to a terminal. |
|
The problem seems to be that Maybe the problem is that SWI-Prolog doesn't distinguish very well between a development environment (which would use |
|
These are related, but distinct issues IMO. Whether or not color support is desirable depends on whether the final application will talk to a console and whether or not it calls things such as print_message/2 or not. The module isn't really a big deal if it does not depend on the time and uri libraries and checking whether or not colors must be used is redone when the state is started (if not, that is a bug). Indeed, which part of the development tools must be included is unclear. Having them around ensures sensible error messages in case the application goes wrong (e.g., a backtrace). We have the One of the things I had in mind for a long time is adding either a SWI-Prolog was never very good at optimizing for small programs ... |
|
Or put How would you access the value of the One reason for making "embedded executables" is to separate the build environment from the deployment environment. The debate over things like shared objects has been going on for years, and I don't see an easy solution. So, until somebody really needs this, maybe just leave it alone? Perhaps I can make the start-up code a bit more easily understand and/or more flexible ... |
And we have print_message/2 calls coming from everywhere that use this stuff. I think that gets a mess. Pushed two commits that no longer make library(ansi_term) depend on the clib package. That at least turns this into simple innocent Prolog code.
Yes. As is though, that is not so easy. The two are pretty tightly connected all over SWI-Prolog. This is not so bad, but it makes the executables a little larger than necessary. As is, a minimal executable is about 235Kb and runs in 20ms (AMD3950X, Linux). As your program grows, the size grows much slower. For example, sCASP is 365Kb source and produces a state of 487Kb, also pulling in many libraries. Startup time of sCASP is 40ms.
Looks like low priority, especially after getting rid of the package and foreign extension dependencies for simple programs. |
The traceback doesn't make sense. When I ran under
gdb, the crash seems to have happened somewhere insidePL_initialise(), where it callsprologTopLevel()(pl-init.c:1247).The text was updated successfully, but these errors were encountered: