On Aug 27, 2024, at 8:52 AM, Christoph M. Becker <cmbecke...@gmx.de> wrote:
>
> Interesting! Just a the other day I (re-?)learned that there are
> usually no "import libraries" (Windows terminology) on Linux, which are
> *very* common on Windows. Such import libraries define stubs (i.e.
> wrappers) for all exported symbols; for functions, basically (pseudo-code):
>
> the_function(a, b, c) {
> module = dl_load("library.dll")
> proc = dl_fetch_symbol(module, "__imp_the_function")
> return proc(a, b, c)
> }
>
> Might roughly be similar on AIX with "the other dynamic linking option".
There isn't something like import libraries, but rather, the shared libs
are actually .a archive files that contain the .so to load at runtime
(of both bitnesses, as well as being able to do things like pack multiple
SOVERs), plus an import file that specifies the name of the library, the
symbols contained within, etc.
My impression is the runtime loader/linker option basically ignores all
of that infrastructure in favour of something that works like what
commodity Unix has, trading AIX's problems with those problems (i.e. lack
of symbol namespacing). Unfortunately, I'm in a situation where I do need
symbol namespacing, so I'm starting to deal with AIX's problems instead.
Unfortunately, I'm not David Edelsohn.
(I wish ELF-world would get symbol namespacing - it would make shipping
binaries far less spooky to debug. Windows gets this right.)
> Well, that is not an option for any binaries we build and ship, since
> the core is not supposed to rely on any external dependencies (that's
> the reason why we still bundle libpcre2 although it is supposed to be
> available almost everywhere).
I didn't know that; it's kinda confusing considering they're all in ext/,
and some vendor (i.e. gd, pcre), but others do not.
