SQLite3 and DynLibs

[xordspar0]

I'm using the SQLite3 package in a small Pascal program and I noticed that my binary is dynamically linked to libc in addition to libsqlite3 (and SDL, but that doesn't come into this story):

Code: Pascal  [Select][+][-]

1. > readelf -d highscores
2.  
3. Dynamic section at offset 0x70db8 contains 28 entries:
4.   Tag        Type                         Name/Value
5.  0x0000000000000001 (NEEDED)             Shared library: [libSDL2-2.0.so.0]
6.  0x0000000000000001 (NEEDED)             Shared library: [libsqlite3.so.0]
7.  0x0000000000000001 (NEEDED)             Shared library: [libSDL2_image-2.0.so.0]
8.  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
9. ...

I wanted to trim down my dependencies to make it easier to deploy my binary, so I looked into what in my program requires libc:

Code: Pascal  [Select][+][-]

1. > nm -u highscores
2.                  w __cxa_finalize@GLIBC_2.2.5
3.                  U dladdr@GLIBC_2.34
4.                  U dlclose@GLIBC_2.34
5.                  U dlerror@GLIBC_2.34
6.                  U dlopen@GLIBC_2.34
7.                  U dlsym@GLIBC_2.34
8.                  w __gmon_start__
9.                  U IMG_LoadTexture
10.                  w _ITM_deregisterTMCloneTable
11.                  w _ITM_registerTMCloneTable
12.                  U __libc_start_main@GLIBC_2.34
13.                  U SDL_AddEventWatch
14.                  U sqlite3_libversion
15.                  (and other SDL stuff...)
16.  

Looks like my program depends on dlopen and friends for some reason. I know that SQLite uses dlopen, but that shouldn't affect the dependencies of my binary.

I found this in sqlite3.inc:

Code: Pascal  [Select][+][-]

1. uses
2.   ctypes,
3. {$ifdef LOAD_DYNAMICALLY}
4.   SysUtils, DynLibs;
5. {$else}
6.   DynLibs;
7.  
8.  

LOAD_DYNAMICALLY is set for sqlite3dyn, but not for sqlite3. However, even when LOAD_DYNAMICALLY is not set, we still use DynLibs. When I made a copy of sqlite3.inc in my project with DynLibs outside of LOAD_DYNAMICALLY removed, my binary doesn't link to libc anymore.

Is this a mistake in sqlite3.inc? I don't see any uses of LoadLibrary except in an {$ifdef LOAD_DYNAMICALLY} block, so as far as I can see there should be no need for DynLibs in this mode. Does this make sense? If so, I'd be happy to submit a patch to fix it, but I just wonder if I'm missing a valid reason for this to be here.

[TRon]

Is this a mistake in sqlite3.inc? I don't see any uses of LoadLibrary except in an {$ifdef LOAD_DYNAMICALLY} block, so as far as I can see there should be no need for DynLibs in this mode. Does this make sense? If so, I'd be happy to submit a patch to fix it, but I just wonder if I'm missing a valid reason for this to be here.

I can't find a valid reason either (other than you have pre-compiled packages installed with your compiler thus requires a rebuild for this particular package, and possible other packages that depend on this particular package/unit)

Seems to me like an oversight but you can never be sure about the motivation when it was introduced so would encourage to create an issue on the bug-tracker (you can attach your patch if wanted) to see if it is considered legitimate.

edit: see PascalDragon's answer right below this post. I stand corrected.

[PascalDragon]

Is this a mistake in sqlite3.inc? I don't see any uses of LoadLibrary except in an {$ifdef LOAD_DYNAMICALLY} block, so as far as I can see there should be no need for DynLibs in this mode. Does this make sense? If so, I'd be happy to submit a patch to fix it, but I just wonder if I'm missing a valid reason for this to be here.

This is by design. The point is that the SQLite library can load its own libraries and for that to work correctly the executable must not be statically linked and instead must link against the C-library. To avoid surprises for users it was decided that even the static import unit has to pull in the C-library (through the DynLibs unit).

[TRon]

Thank you for the explanation about the motivation of/for that choice PascalDragon.

I stand corrected.

[xordspar0]

The point is that the SQLite library can load its own libraries and for that to work correctly the executable must not be statically linked and instead must link against the C-library. To avoid surprises for users it was decided that even the static import unit has to pull in the C-library (through the DynLibs unit).

Thanks for the explanation. Just to clarify, when I use SQLite3.pp (LOAD_DYNAMICALLY is not set), my binary dynamically links to libsqlite3.so. The options are to dynamically load SQLite at runtime or to dynamically link to it. Are you saying that if the user overrode the default settings and statically linked libsqlite3.so into the main binary, then the user might run into a surprise of needing to link to libc?

[xordspar0]

Ah, something I didn't think of at first is that even if I can get my binary to not link against libc, it still depends on the dynamic loader from the libc I had at build time:

Code: [Select]

> file highscores
highscores: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, for GNU/Linux 2.4.0, with debug_info, not stripped

I was hoping my binary could magically work on any system with a Linux kernel and a working libSDL2.so, but I couldn't get away from being tied to a particular libc. In that case, it doesn't make much difference if my binary depends on one of a few symbols from libc.

[Zvoni]

Don't forget the visual components (DBGrid et al).
How are those suppossed to work during design-time if not dynamically?