Linux freebasic portability issue

Linux specific questions.
Post Reply
Helium5793
Posts: 42
Joined: Jun 21, 2016 13:06

Linux freebasic portability issue

Post by Helium5793 »

One of the problems I have with my FB programs is that they are not portable to other linux machines. This is mostly a shared library thing as the other users have to install the same libraries I have installed. I have tried to use static libraries, but the problem there is that many static libraries are not available, at least under Fedora. I have been able to find a few, but not enough. I have searched for how to create static libaries and found a few sets of directions, but none have worked in my hands.
So my questions:
1. Is there an easy way to create static libraries that I don't know about (like converting the shared library)?
2. Is it possible for FB to incorporate the shared libraries into the compiled code so it no longer needs the shared library?

I realize that shared libraries came along to save memory and keep programs small. However computers now have lots of memory and portability seems a greater issue. I have seen python programs (and other languages) often have a similar problem as library updates break programs, and there are special ways to run programs so that they can keep using some old version that they work with. This appears to be a growing problem, and is trying to be answered by AppImage and several other devices which force the author to create a whole set of libraries that travel with the program so it can be run on various linux flavors. I think compiling with static libraries would do the same thing, but I am finding it difficult to get the appropriate static libraries. Is there any place to download or create static libraries, or a flavor of linux that includes static libraries in its installation???
Thanks for any help or comments,
John
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Linux freebasic portability issue

Post by TJF »

The LINUX way for this issue is: build a package that installs your executable, as well as all the dependencies.

If you don't like to learn that, you can ship your executable with an install script, that copies the binary to the right place and starts the (distribution specific) package manager to fetch the missing libraries.

Regards
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: Linux freebasic portability issue

Post by Landeel »

Linux executables won't automatically load libraries from the same directory, as PE .exe does.
Distribute the needed libraries with your application, I recommend putting them in a sub-directory.
Instead of running the program directly, use a runner script to set 'LD_LIBRARY_PATH' and then run the program:

Code: Select all

#!/bin/bash
cd "$(dirname "$0")"
env LD_LIBRARY_PATH=mylibdir ./myprogram
Also, GLIBC is not forward-compatible.
If you need your program to be compatible with older distros, compile it using an older distro (use a virtual machine), or try my fb snap packages.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Linux freebasic portability issue

Post by caseih »

Linux software distribution has always been a thorny one, especially for use cases such as yours. At one time users were expected to compile things from a source tarball, which is a bit hard with FB, because users would probably have to compile FB first!

Besides the package route (which is distro specific and distro version specific), many programs like firefox are place in /opt/ and a script is placed in /usr/bin to set up the LD_LIBRARY_PATH and execute the binary.

Flatpaks are another packaging technology that many are using. Flatpak provides certain base environments that the flat packs are based on, pinning glibc version, etc). They do work quite well across different distros and even different versions of distros. However that's a pretty heavy weight solution for your needs!

Another promising system is AppImage. I think if I were to distribute binaries I would choose this route. But building the AppImage can be a bit complicated, as you might need a chroot image to work in, that has older libraries that would be compatible with newer distros (the old glibc issue that @Landeel talked about).

Sigh. My favorite operating system can sure be awkward!
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: Linux freebasic portability issue

Post by Landeel »

Depending on what you're doing with those libs, you could use clever DYLIBLOAD/DYLIBSYMBOL instead of dynamic linking.
I'm doing that with SDL in my games.
Helium5793
Posts: 42
Joined: Jun 21, 2016 13:06

Re: Linux freebasic portability issue

Post by Helium5793 »

Thank you all for your replies. You have given me several ideas I need to go back and try.
John
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: Linux freebasic portability issue

Post by TeeEmCee »

Hello, I have experience compiling portable FB binaries that work on (AFAIK) any linux system since ~2011. See https://rpg.hamsterrepublic.com/ohrrpgc ... x_binaries

ncurses is so unportable that it's killing FreeBasic on Linux. Getting rid of this dependency is the first order of business. You can use my termcap_stub.c to do so.

Libraries like SDL 2, while common, are still commonly missing. If you don't just tell your users to install them, include the libraries or statically link them, as said. I believe it's possible to use a link-time flag instead of a runtime LD_LIBRARY_PATH flag, but noone seems to do that.
Landeel: is is actually necessary to use DYLIBLOAD/DYLIBSYMBOL with SDL? I do this only to load optional functions that are only present in recent SDL versions. I'm not aware of any ABI changes but I'm not 100% sure about it.

Technically glibc should not be statically linked, because its version needs to be compatible with that of the glibc data files installed on the system (tzinfo and translations and maybe other things). But I don't know if this is a real problem in practice.
Instead you can dynamically link to a recent glibc but check that you don't call any functions in it that aren't there in older versions. See the page I linked.
Note that you would need to do this for all the libraries you distribute.

Compiling on an old Linux distro is very commonly recommended, but it will neither make your binaries automatically portable, nor is it necessary.
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: Linux freebasic portability issue

Post by Landeel »

Hey TeeEmCee!

About ncurses, the problem is libtinfo, right? I had problems with it after I upgraded to Ubuntu 20.04. But copying 'libtinfo.a' to '/usr/local/lib/freebasic/linux-x86_64/' solved it for me. I don't know the internals, but this causes libtinfo to link statically.

The reason I'm using DYLIBLOAD with SDL.
I use OpenGL for graphics. SDL is not a hard dependency for me, as I'm using it only for audio, and as an optional fallback for input and window handling.
It works like a plugin. If I add a different backend for audio, I won't be needing SDL at all.
Well, I distribute the SDL and SDL_mixer libs with my games, but the executable will look for the libs in the system before it tries to use the ones I ship.
I made it so it will work with either SDL 1.2.x or SDL 2.0.x.
Even if it fails to load SDL at all, the program won't fail silently, so I'll be able to display a warning.

Compiling with older distros is just a beginner friendly way to get around the GLIBC version issue.
Recently I've made experimental snap packages of fbc using the 16.04 core. Binaries compiled with it ran in all *Ubuntu versions from 12.04 to 20.04. I suppose they will work with Debian too. I haven't tried with other distros yet.
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: Linux freebasic portability issue

Post by TeeEmCee »

Ah, cool. I'm planning to switch to dynamically loading SDL and SDL_mixer too so that I can use either SDL 1.2 or 2.0, whichever is present: I have separate graphics and audio backends based on SDL 1.2 and 2.0 but can't currently link both into the engine at once.

Statically linking libtinfo would probably work. It does read data files for the terminal definitions obviously, but I doubt that those are version-specific. I didn't consider doing that because my distro (Slackware) doesn't even include static builds of libtinfo, libtermcap, or libncurses... I wonder why.
Post Reply