[PB 6.00 x86 Beta 7] GLIBC_2.28 not found

[Shardik]

This morning I have downloaded PureBasic 6.00 Beta 7 for Linux (Debian 10 - x86) and tested it on 9 different x86 Linux distributions. In 7 from 9 distributions I wasn't able to start PB 6.00 x86 Beta 7. When starting from console I obtained the following error message:

/lib/i386-linux-gnu/libc.so6: version `GLIBC_2.28' not found (required by /media/PureBasic/6.00_Beta_7/compilers/purebasic

The GLIBC version was always 2.27:

ldd --version
ldd (Ubuntu GLBBC 2.27-3 ubuntu 1.6)

These are the tested Linux distributions ([+] PureBasic is starting, [-] GLIBC_2.28 not found) which were all updated with all available updates before trying to start PureBasic:
[+] Debian 10 x86 'Buster' with LXDE
[-] Linux Mint 19 x86 'Tara' with Cinnamon
[-] Lubuntu 18.04 x86 LTS
[+] MX Linux 19.4 x86
[-] Kubuntu 18.04 x86 LTS
[-] Ubuntu 18.04 x86 LTS
[-] Ubuntu Budgie 18.04 x86 LTS
[-] Ubuntu Mate 18.04 x86 LTS
[-] Xubuntu 18.04 x86 LTS


A similar problem with GLIBC_2.28 existed with the Raspberry Pi version where PureBasic didn't start on older Raspberry Pi OS versions because PureBasic was compiled with GLIBC_2.29.

Is it possible to link the lib statically for the Linux x86 version of PureBasic like it has already been done for the Raspberry Pi?

I just pushed a new Raspberry 6.00 beta 4 package which links the libm statically to avoid the 2.29 dependency, could you give it a try ?

Ubuntu 18.04 x86 (Bionic Beaver) is a LTS version with hardware and maintenance updates up to April 2023 and paid Extended Security Maintenance (ESM) up to January 2028. So it would be nice to be able to use Ubuntu 18.04 x86 LTS and its derivatives with the new PB 6.00...

[deeproot]

Ubuntu 18.04 x86 (Bionic Beaver) is a LTS version with hardware and maintenance updates up to April 2023 and paid Extended Security Maintenance (ESM) up to January 2028. So it would be nice to be able to use Ubuntu 18.04 x86 LTS and its derivatives with the new PB 6.00...

Thanks for posting this - I had misunderstood the lifecycle of Ubuntu 18.04 - thought it ended this year, maybe confused it with Mint 18.

I don't myself use any Ubuntu except very occasionally as live-USB. However, from web searches there appears to be a strange thing: - Ubuntu 18 is more-or-less based on Debian 10 (buster). Debian 10 has GLIBC version 2.28, but weirdly Ubuntu 18.04 has 2.27 (https://repology.org/project/glibc/versions)

In addition to PB 6.00 as above, this has implications for releasing compiled programs as I have customers running various Ubuntu versions.

[Fred]

Is it also the libm which is causing error or another lib ?

[deeproot]

Is it also the libm which is causing error or another lib ?

I don't have a copy of Ubuntu 18.04 easily available so cannot test - very sorry!! - - Hopefully others can help with this.

But I have just done a quick test of Linux Mint 19.3 x83, which has an Ubuntu 18.04 base. PB 6.00 Beta 8 x86 only gives the error "GLIBC_2.28 not found" when started from command line. Not sure if there are any other lib issues as this was just a very quick check on a live USB.

Using "ldd --version" shows Mint 19.3 x86 (and x64) has GLIBC version 2.27 - it is supported to April 2023.

PB 6.00 B8 x64 Ubuntu-18 build runs fine on the x64 install of Mint 19.3

[Shardik]

Is it also the libm which is causing error or another lib ?

No, it seems to be libc.so.6:

$ objdump -p purebasic

Versionsreferenzen:
...
von libm.so.6 benötigt:
0x0d696911 0x00 18 GLIBC_2.1
0x0d696910 0x00 16 GLIBC_2.0
von libdl.so.2 benötigt:
0x0d696911 0x00 17 GLIBC_2.1
0x0d696910 0x00 15 GLIBC_2.0
von libpthread.so.0 benötigt:
0x0d696912 0x00 22 GLIBC_2.2
0x09691972 0x00 14 GLIBC_2.3.2
0x0d696910 0x00 09 GLIBC_2.0
0x0d696911 0x00 07 GLIBC_2.1
...
von libc.so.6 benötigt:
0x09691f73 0x00 23 GLIBC_2.1.3
0x09691a73 0x00 21 GLIBC_2.2.3
0x0d696911 0x00 12 GLIBC_2.1
0x06969188 0x00 11 GLIBC_2.28
0x0d696913 0x00 10 GLIBC_2.3
0x0d696912 0x00 08 GLIBC_2.2
0x0d696910 0x00 02 GLIBC_2.0


$ objdump -T purebasic | fgrep GLIBC_2.28

00000000 DF *UND* 00000000 GLIBC_2.28 fcntl64
00000000 DF *UND* 00000000 GLIBC_2.28 fcntl

So fcntl and fcntl64 seem to be the culprits.

[Fred]

Unfortunately, I don't think you can statically link libc easily