Extra libraries needed on Linux

[Chris Iverson]

So, I've accidentally stumbled on a couple of extra libraries needed by LB5 on Linux. I don't know if they're actually used, but they're loaded by LB5.

(Note that, in all of these examples, I modified 'simple database.bas' to properly load the sqlite library, as well.)

chris@shinoko:~$ cat lb5loadlog-i386.txt | sort | uniq
dlopen() -  - 0x00000101 - 0xf7f9c990
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libXcursor - 0x00000001 - 0000000000
dlopen() - libXcursor.so - 0x00000001 - 0000000000
dlopen() - libXcursor.so.1 - 0x00000001 - 0000000000
dlopen() - libXft.so.2 - 0x00000101 - 0000000000
dlopen() - (null) - 0x00000101 - 0xf7f9c990
dlopen() - /usr/lib/i386-linux-gnu/libsqlite3.so.0 - 0x00000101 - 0x0bb3e830

(The columns are the function name(always dlopen(), which loads libraries), the name of the library being loaded(if this is null, I think it's trying to load the original program binary), the flags sent to the dlopen() call, and the return value. If the return value is 0, the load failed.)

They are libXcursor(a cursor management library for X), and libXft(a font rendering library for X).

The reason I'm bringing this up is because, they're normally installed by default if you have X installed, so no issues arise.

However, I did find once instance where they were NOT already installed: if you're running 32-bit LB5 on 64-bit Linux.

When doing so(32-bit LB5 on Ubuntu 64-bit), I found that LB5 tried(and failed) to load the libXft library over 7,000 times, and also tried and failed to load libXcursor.

When I checked to see why(and compare to 64-bit), I realized that Ubuntu did not install the 32-bit versions of those libraries by default, so I had to manually install them.

I will be flagging them as dependencies in future versions of my package, but if you want to make sure you've got the right libraries(and you're not using the 64-bit version of LB5), you can install the 32-bit versions of libXcursor and libXft from APT using the following command:

sudo apt install libxft2:i386 libxcursor1:i386


Looking at the above, I also notice that the load for libcrypto fails, and it does the same for 64-bit Ubuntu, but it succeeds on the Pi. (libcrypto is OpenSSL; the Linux equivalent of SChannel for TLS/SSL encryption.)

x86-64 Linux:
chris@shinoko:~$ cat lb5loadlog-x86-64.txt
dlopen() - (null) - 0x00000101 - 0x00007f667d7d6190
dlopen() - libXft.so.2 - 0x00000101 - 0x0000000004d1f240
dlopen() - libXcursor.so.1 - 0x00000001 - 0x0000000004e1eb30
dlopen() -  - 0x00000101 - 0x00007f667d7d6190
dlopen() - libcrypto.so - 0x00000101 - 000000000000000000
dlopen() - /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 - 0x00000101 - 0x0000000004e0d330


Raspberry Pi 4(Raspbian):
chris@rpi4:~ $ cat lb5loadlog-rpi32.txt
dlopen() = (null) - 0x00000101 - 0xb6f45978
dlopen() = libXft.so.2 - 0x00000101 - 0x024554e8
dlopen() = libXcursor.so.1 - 0x00000001 - 0x02493da0
dlopen() =  - 0x00000101 - 0xb6f45978
dlopen() = libcrypto.so - 0x00000101 - 0x024842c0
dlopen() = /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0 - 0x00000101 - 0x024647e8


I note that, on the Pi, there is a symbolic link connecting libcrypto.so to libcrypto.so.1.1, that doesn't exist on Ubuntu by default.

LDCONFIG and the library folder on the Pi:
chris@rpi4:~ $ ldconfig -p | grep libcrypto
       libcrypto.so.1.1 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
       libcrypto.so (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libcrypto.so
chris@rpi4:~ $ ls -l /usr/lib/arm-linux-gnueabihf/libcrypto.so*
lrwxrwxrwx 1 root root      16 Mar 25 11:22 /usr/lib/arm-linux-gnueabihf/libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root 2122144 Mar 25 11:22 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1

LDCONFIG and the library folder on Ubuntu x64:
chris@shinoko:~$ ldconfig -p | grep libcrypto.so
       libcrypto.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
chris@shinoko:~$ ls -l /usr/lib/x86_64-linux-gnu/libcrypto.so*
-rw-r--r-- 1 root root 2954080 Mar 22 06:37 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1


I don't know why that link doesn't exist, and I don't know if it's something that needs to be manually fixed. I'm going to look at a different install of Ubuntu to check if it's the same, but it appears the same on my Ubuntu box and in my Ubuntu WSL install.

Since LB5 doesn't seem to be doing anything with TLS at the moment, it probably doesn't matter that the load fails, but I'm not actually sure why that symbolic link wouldn't be there.

[Stefan Pendl]

TLS might be used by the httpget command.
I have to change the HTTPS protocol to HTTP to get the HTTPGET sample shipping with LB5 to work for example.

[Carl Gundel]

Apr 29, 2021 4:07:46 GMT -5 Stefan Pendl said:

TLS might be used by the httpget command.
I have to change the HTTPS protocol to HTTP to get the HTTPGET sample shipping with LB5 to work for example.

I am working to solve the HTTPGET function fixed.  As for the XFT libraries, is XFT installed in your Linux distro?  EDIT: I went back a re-read your post.  I see that the 32-bit XFT libraries were not installed by default on your 64-bit Ubuntu.  Linux really can be a pain when it comes to foundational stuff like the window manager, the fonts that come installed, and other stuff like that.

[Stefan Pendl]

From my point of view, UNIX systems are better in specifying dependencies of software packages.
If you have a 64-bit platform, 64-bit applications are installed by default.
If you install 32-bit applications the package will have to include links to all the needed 32-bit dependencies.
64-bit UNIX systems have been available from the mid-90th, where 64-bit Windows started around 2003.

Why install all the 32-bit packages just because it could be possible that one will install a 32-bit package?
UNIX systems are build for performance and reliability, not to handle all possibilities a user can think of.

[Stefan Pendl]

Chris Iverson, is there still a difference in the underlying libraries when one uses a different desktop manager (Cinnamon, MATE, Xfce, etc.).
My knowledge in this section is ancient, if any desktop manager uses X-windows as the framework, this question can be ignored.

[Chris Iverson]

As far as I'm aware, if you're running anything based on X windows, or providing X windows compatibility, there shouldn't be a difference in the underlying libraries. At least, not what they're called, and their API. Whether it's a different library internally is a different question, but if it's aim is to be compatible, then it should be irrelevant.

Most window managers actually run at a level above X itself, and remain compatible.

There is a replacement windowing system being slowly rolled out in the Linux world(Wayland), but even that has X compatibility.


And I should point out that in general, it's less common to be running 32-bit software on a 64-bit Linux OS, simply because most of the software you'd be running on Linux would just be recompiled for 64-bit anyway. And in this case, even if the libraries weren't installed, they were at least easily available to install, and one doesn't have to go searching randomly across the internet for them.