[lld] RFC: Finding shared libraries on OpenBSD

On OpenBSD we still use the "classic" SunOS 4 shared library
versioning scheme where the major and minor number are part of the
library name (and recorded in DT_NEEDED entries). For example the
shared libc on the OpenBSD-current is named libc.so.89.2. With this
scheme, linker has to pick the pick the library with the highest major
and minor (within the highest major version); the symbolic links
present on most other ELF-based systems don't exist on OpenBSD. The
diff below implements this search algorithm. It follows the same
approach of iterating over files in a directory as the implementation
in the native (ld.bfd derived) toolchain.

This is an RFC as I'm not sure the diff is the best way to implement
this. For one thing, iterating over files is probably undesirable on
non-OpenBSD systems. And the searching code should probably be moved
to its own function.

Index: ELF/DriverUtils.cpp

Hi Mark,

If we have to do this, or LLD doesn’t work on OpenBSD, I think we need to do this. But can I ask one question? I wonder why OpenBSD systems don’t have symbolic links unlike the other Unix-like systems in the first place.

From: Rui Ueyama <ruiu@google.com>
Date: Mon, 19 Dec 2016 20:07:39 -0600

Hi Mark,

If we have to do this, or LLD doesn't work on OpenBSD, I think we need to
do this. But can I ask one question? I wonder why OpenBSD systems don't
have symbolic links unlike the other Unix-like systems in the first place.

I suppose the main reason is to minimize the differences between ELF
and a.out systems. The transition was done on an architecture by
architecture basis and took several years to complete.

Whenever the subject came up in the past, there were concerns about
managing the symlinks. But the real problem is that the system
libraries get built without an DT_SONAME. That results in the wrong
name being recorded in DT_NEEDED entries, breaking the versioning
scheme.

Anyway, I'll bring it up on the OpenBSD side, and see if we can work
something out. It's been a while since the issue came up last.

Thanks,

Mark