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?
