On Sun, May 31, 2026 at 09:32:24PM +0200, Nikolaj Thygesen wrote: > On Sun, 31 May 2026 22:23:02 +0300 > Konstantin Belousov <[email protected]> wrote: > > > On Sun, May 31, 2026 at 09:09:23PM +0200, Nikolaj Thygesen wrote: > > > In lang/swipl the .so: > > > > > > /usr/local/lib/swipl/lib/amd64-freebsd/uuid.so > > > > > > ... is linked with: > > > > > > USES = localbase:ldflags > > > LIB_DEPENDS = libossp-uuid.so:misc/ossp-uuid > > > > > > ... which works fine build-time, and running: > > > > > > readelf -d /usr/local/lib/swipl/lib/amd64-freebsd/uuid.so > > > > > > ... returns: > > > > > > Dynamic section at offset 0x1530 contains 23 entries: > > > Tag Type Name/Value > > > 0x0000000000000001 (NEEDED) Shared library: > > > [libstdthreads.so.0] 0x0000000000000001 (NEEDED) Shared > > > library: [libossp-uuid.so.16] 0x0000000000000001 (NEEDED) > > > Shared library: [libc.so.7] > > > > > > ... though the order doesn't seem to matter. At runtime Lldb shows > > > all libs loaded fine, but when calling e.g. read_uuid() the program > > > crashes when calling libc.read_uuid() in place of > > > ossp-uuid.read_uuid() due to a name clash. I can "fix" this by > > > doing: > > > > > > LD_PRELOAD=/usr/local/lib/libossp-uuid.so > > > <program-using-uuid's> > > > > > > ... but this seems like an unfortunate situation. Is there a more > > > proper solution to this situation? I see a few other ports > > > LIB_DEPENDING on the same port, and I wonder how they can work!? > > > > What matter is the order of the global NEEDED graph for the binary. > > If there is some library that depends on libc.so.7 (or libc.so.7 > > itself) which is loaded in the global NEEDED order before > > libossp-uuid.so.16, then it gets a priority in resolving the symbols. > > > > ... that makes sense - so what can I expect from "USES=localbase:ldflags"? > From your reply it sound slike there's no workaround?
The expected fix is to list the libraries in the right order on the static linker command line. How to achieve this with the build system for the program is the next question. I am not sure that the port framework has something better there than a proposal to patch the sources, assuming the used build system is flexible enough.
