Building static self-contained Prolog binary

[redfast00]

I would like to build a static Prolog binary that has the Prolog library built in, so it can easily run on other systems. Is this possible?

As a first step, I tried to statically build the swipl library itself by following the build instructions and replacing the cmake command with cmake -DSWIPL_STATIC_LIB=ON .. (as per the instructions), but this did not result in a .a file anywhere in the build directory.

[JanWielemaker]

I would like to build a static Prolog binary that has the Prolog library built in, so it can easily run on other systems. Is this possible?

Yes, it is possible. Although, if you want to use the foreign extensions it will only work on ELF based platforms (notably Linux). The other problem is that I demonstrated that about 4 years ago. It never became part of the regular maintained build configuration though and is thus unmaintained and apparently broken :cry:

You can revive it. We also have a company that can help.

[redfast00]

We hacked some more on it yesterday night, and managed to work around it by putting the binary and all libraries it needs into an AppImage. It's pretty bloated (it turned a 500K binary into 250M), but it works on most Linux x86 systems (as long as the kernel is recent enough).

As for reviving this: do you think this is feasible to do for someone pretty new to Prolog (but with some C experience) in 2 days? If so, could you give some pointers of where to look? Hiring your company won't be feasible, we're a student association.

[JanWielemaker]

Not that there is also a snap image. On most systems simply snap install swi-prolog should do the job.

As for reviving this: do you think this is feasible to do for someone pretty new to Prolog (but with some C experience) in 2 days?

Hard to say. Actually creating a version that does not use libswipl.so is still seems to work:

cmake -DSWIPL_SHARED_LIB=OFF -G Ninja ..
ninja
ldd src/swipl
	linux-vdso.so.1 (0x00007ffd08923000)
	libtcmalloc_minimal.so.4 => /lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4 (0x00007fee2964e000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007fee2961f000)
	libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fee2959c000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fee29580000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fee2949c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fee29272000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fee29059000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fee2903f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fee299f0000)

You'd have to change the CMake config to link statically. As a result you probably can't dynamically load extensions any longer (e.g., graphics, socket support and a lot more).

The next step is to create a single file system by adding the library to the source file and appending this to the executable. I have forgotten how that works. When I find time I'll have a look whether I still have those instructions. If the target is Linux though, what is wrong with snap?