Re: How do I avoid using LD_PRELOAD

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.