On 26.08.2024 at 20:05, Calvin Buckley wrote:
> Dynamic linkers that pull from a general symbol slurry (your typical ld.so
> for instance) don't have a problem with it, but some platforms have more
> strict linkage, like Windows. IIRC, things like PDO are built into the PHP
> executable/library for this reason. I know AIX can actually do it both ways;
> I used to build the ld.so style way (they call it "runtime linking"), but it
> turns out that causes problems with different versions of symbols (i.e.
> OpenSSL 1.1 and 3.0 in same address space), so I had to switch to building it
> with the other dynamic linking option, which means I have to make the same
> build compromises as on Windows.
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".
> As such, it might be a bit tricky for people on Windows/AIX; the easiest
> solution if PHAR is using the openssl extension's symbols would be to not
> build the openssl extension as shared.
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).
Christoph
