On Tue 23 Jul 2024 at 09:52:10 -0400, Greg Troxel wrote: > For the second point, we sort of need linker support for > > A links to > > B (new sqlite3 from pkgsrc) > > C (libfoo in netbsd base), which links to > > D (old sqlite3 from base > > and have C's use of sqlite3_bar symbols resolve to D while A's use > resolves to B. And similarly for other graphs. I may be off, but I > have the impression this does not work, at least reliably. I believe Apple/MacOS has a linker model (somewhat?) like that. They call it two-level namespace": "The two-level namespace feature of OS X v10.1 and later adds the module name as part of the symbol name of the symbols defined within it. This approach ensures a module's symbol names don't conflict with the names used in other modules. " (https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/executing_files.html). I didn't dig deep enough to know if in our case, if B and D are the same library but with a different version number, or a different path name, this would also manage to distinguish the two. I guess the trouble is basically because Sun, when they introduced dynamic libraries, decided on a flat namespace so that it would be as similar to static libraries as possible. (https://www.cs.cornell.edu/courses/cs414/2001FA/sharedlib.pdf) Fortunately we got rid of one of those similarity "advantages" already: when linking A dynamically, you only need to link with B and C, and C pulls in D (or the linker knows that C needs D and pulls it in). When linking statically, all 4 need to be specified. Now this same thing only needs to be done by the runtime linker... (Hopefully better, because if you have two different versions of libgcc.so or libstdc++ of the same version number, things work better if they are not mixed up) -Olaf. -- ___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl> \X/ There is no AI. There is just someone else's work. --I. Rose
Attachment:
signature.asc
Description: PGP signature