STATIC and SHARED Libraries linking problem

Linux specific questions.
Post Reply
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

STATIC and SHARED Libraries linking problem

Post by VANYA »

Many people have noticed that the compiler requires libtinfo.so.5
On some distributions this can be installed from the repository, but on others it is not, and sometimes hard to find.
What do compiler developers do? Build the compiler with libtinfo.so.6? But then it won't work on older distributions because they use libtinfo.so.5
How do I solve this problem? It is possible to link compiler and RTLIB statically with libtinfo.a
But how stable will it work?

Example assembly of my program:
On x86 there is no problem. I did that and everything compiles and works.
But on x86-64 I have a problem:
My program besides the executable has also plugins with dynamic libraries. The program itself compiles without problems, but the dynamic libraries require that libtinfo.a be built with the -fPIC flag.
I built libtinfo.a and libpangox-1.0.a with flag -fPIC. The compile succeeded. But the program became unstable (sometimes CRASH).

How to solve the binding problem on x86-64? Does anyone know the solution?
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: STATIC and SHARED Libraries linking problem

Post by caseih »

Just curious which distributions can libtinfo.so.5 not be installed from standard distro repos? Of all the major distros and their derivatives, Arch, Debian, Ubuntu, Fedora, and OpenSUSE all provide libtinfo.so.5 in a package. Although I'm least sure about OpenSUSE.

One solution is to put the parts, or implementations of the parts, of libtinfo that FBC needs in the FBC source code. I thought at one time someone had worked on that.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: STATIC and SHARED Libraries linking problem

Post by VANYA »

I won't be able to list the distributions that don't contain libtinfo5 now, because I did the tests 1-2 years ago, but at least the guys listed some of them here:
viewtopic.php?t=31416

Yes, I saw your answer in this thread that the libraries can be found on third party sites. This usually forces users to install libraries from past releases. I don't think this is a very good approach. It is more correct to relieve users of this dependence.

There are many such distributions among not very popular distributions, and there will be more and more of them every year. This issue is relevant.

At the moment the compiler won't even run without libtinfo5|ncurses5. And this same disease applies to all programs created in FreeBasic, even those with a graphical interface where ncurses is not required. Even most console programs should not require libtinfo|ncurses. For example, take any simple C language console program, where this dependency is not required.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: STATIC and SHARED Libraries linking problem

Post by caseih »

I just mean that when you're not sure what package ships a particular library in your distribution, you can use one of the RPM search sites to identify it, and then use your distro tools to install it from the official repos. Another way is just with the distro's own package manager search tool (apt search or dnf search for example).

But I would never recommend blindly downloading a package from a random place on the internet.

My point was that all the major distros still ship libtinfo.so.5 to this very day and it's just a matter of installing the right package from the distro's own package repository. So really the standard answer for all FB users who encounter this problem is to install the appropriate package from their distro's repository. On Ubuntu and Debian it is "libtinfo5" and "libncurses5" and on Fedora, RedHat, or CentOS it is "ncurses-compat-libs". So the instructions users should receive would be:

For Debian, Ubuntu, or Mint (and any Debian-derived distro):

Code: Select all

sudo apt install libtinfo5 libncurses5
For Fedora, RedHat, CentOS, AlmaLinux:

Code: Select all

sudo dnf install ncurses-compat-libs
Hopefully arch and opensuse users can contribute their instructions.

Obviously FB's binary packages could be built against the current version of ncurses if they didn't care about older LTS distros. This issue doesn't just affect FB. It also effects many other tools, which is why all the distributions I know of still ship the older version of the libraries along side the new ones. It's just that they aren't there by default.

If someone volunteered to maintain a flatpak version of FB, they could just bundle the libtinfo library needed with the flatpak. There are definitely solutions there, but they all come at some cost and FB dev resources are quite limited.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: STATIC and SHARED Libraries linking problem

Post by VANYA »

I'm talking about the fact that it would be good to get rid of unnecessary dependencies for both the compiler and the programs created in it.
You can get rid of libtinfo 5 or 6 at least for the compiler. Maybe it can be done even for rtlib.
But as I understand it, the issue of getting rid of unnecessary dependencies is not even considered?

Let's take a simple C program:

Code: Select all

#include <stdio.h>

int main()
{
  printf("Hello world\n");
  return 0;
}
We compile , pass on to other people and they will be able to run this program on any LINUX distribution!

We take absolutely any FreeBasic program and you will not be able to run it until you install libtinfo|ncurses.

Think:
why do you need libtinfo|ncurses for GUI programs?
or why is libtinfo|ncurses needed for programs where only output to the terminal with print|printf ?
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: STATIC and SHARED Libraries linking problem

Post by caseih »

Yes it may well be desirable in many circumstances to avoid needing a dependency for the simplest cases.

But if you want to use LOCATE or COLOR in the terminal in your FB program, the runtime library needs to know the terminal escape codes, and that can vary by terminal (hence the dependency on libtinfo), although in real life nearly all terminal implementations have pretty much now standardized on whatever "xterm" uses. Real serial terminals are obviously a thing of the past now. So maybe the bulk of tinfo's functionality could be forked and added to the runtime library itself.

I should note that even if the compiler is using libtinfo.so.5 internally, any EXE you create is linked to whatever version of libtinfo is your system default. On my machines that is libtinfo.so.6. A side effect of this is that my EXEs could not run on older distros that use libtinfo.so.5. So yes I agree this can be an issue for distributing programs created with FB. Not sure the best solution.
Post Reply