ld.so system not working properly

[kegon]

I did the symlinking. As I understand it, linking doesn't matter as long as the absolute path resolves to the correct .so and the version numbering is also correct. I have used this type of linking before and never had any problems with it.

For thoroughness, I redid the linking in the way you describe and relinked the binary but it didn't help.

I took the binary elements of these libraries from what is now a deprecated package from Jessie. I had previously used on Sid, Jessie and then Stretch.

Refs:
https://packages.debian.org/search?keywords=libdispatch
https://github.com/mheily/libkqueue
https://github.com/apple/swift-corelibs-libdispatch

[Chrisdb]

What's the output now of

Code: Select all

ls -l | grep "kqueue"

And

Code: Select all

file libkqueue.so.0.0


Since you compiled the executable with rpath, it won't make Any difference if you pass the lib directory to 'lo.so.conf'

[kegon]

@Chrisdb

Code: Select all

$ ls -l libkq*
-rwxr-xr-x 1 kegon kegon 170528 Jan 16  2019 libkqueue.so
lrwxrwxrwx 1 kegon kegon     12 Feb 17 19:22 libkqueue.so.0 -> libkqueue.so
lrwxrwxrwx 1 kegon kegon     14 Feb 16 22:33 libkqueue.so.0.0 -> libkqueue.so.0

$ file libkqueue.so
libkqueue.so: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=9328028820c04741832ec8d74df282e965d4de03, with debug_info, not stripped

I guess this ^ is the problem - it's seen as a SYSV PIE executable. I'm sure I was using this library's binary before; I wouldn't have renamed some executable to be a library. Probably something in the kernel changed when I moved to Buster and previously some compatibility thing kept the old version working until then. Seeing as though I have source, I will have to try to compile my own.

Thanks for all the help.

If I'm right, it's been interesting to learn that ldconfig did some kind of check that libraries are in fact shared objects.