Re: Power-up cc --print-file-name for .so names
Christian Weisgerber wrote: > Mark Kettenis: > > > There is a scenario where this goes wrong. If a shared library lacks > > a DT_SONAME entry, the library filename is used to generate the > > DT_NEEDED entries. But I would consider such a shared library broken > > and we fixed base a lng time ago. Some care has to be taken when > > adding the symlinks to shared libraries in ports. But I'm sure the > > package management stuff could check that shared libraries in ports > > have a DT_SONAME entry. > > We never proceeded to clean that up in ports. > > I just extracted all packages from the latest amd64 snapshot, and > out of a total of 3551 shared libraries, 593 do not have a SONAME. I suspect utilizing SONAME for ABI crossing is more of a myth, because no other systems actually has multiple shared library versions no other systems do ABI breaking changes in this way.
Re: Power-up cc --print-file-name for .so names
Mark Kettenis: > There is a scenario where this goes wrong. If a shared library lacks > a DT_SONAME entry, the library filename is used to generate the > DT_NEEDED entries. But I would consider such a shared library broken > and we fixed base a lng time ago. Some care has to be taken when > adding the symlinks to shared libraries in ports. But I'm sure the > package management stuff could check that shared libraries in ports > have a DT_SONAME entry. We never proceeded to clean that up in ports. I just extracted all packages from the latest amd64 snapshot, and out of a total of 3551 shared libraries, 593 do not have a SONAME. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Power-up cc --print-file-name for .so names
Mark Kettenis wrote: > > From: "Theo de Raadt" > > Date: Mon, 14 Feb 2022 00:34:53 -0700 > > > > > The solution would be to add symlinks like all the other OSes do. But > > > Theo doesn't like that. > > > > No, the problem is you add symbolic links, how long before software > > ecosystems in ports choose the short names in linkage -- "because it > > also works"? If they do so, all the transition benefits we have gained > > from the #.# names is lost. Forever. > > Nope. When linking against a shared library, the full #.# name is > taken from the DT_SONAME entry of the shared library and recorded as a > DT_NEEDED entry in the executable. And those DT_NEEDED entries are > used by the dynamic linker to lookup the shared libraries. I doubt that is the only mechanism that looks at names and numbers.
Re: Power-up cc --print-file-name for .so names
Mark Kettenis wrote: > > From: Philip Guenther > > Date: Sun, 13 Feb 2022 23:29:06 -0800 > > > > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis > > wrote: > > > > > From: Greg Steuck > > > Date: Sun, 13 Feb 2022 22:37:13 -0800 > > > > > > To give a sense of the kind of change required to get the feature I > > > want, see the patch at the end. The change in DriverUtils.cpp is just > > to > > > show that the same function is hiding in there. > > > > > > If this looks like a good direction, I can cleanup the code and maybe > > it > > > could be shared, though I'm not sure where this would belong. Maybe a > > > new tiny library of such wrappers to maintain in our tree? > > > > > > Thanks > > > Greg > > > > > > P.S. Naturally, once I install this patched cc, ghci is suddenly very > > > happy. > > > > Something like this was rejected upstream. > > > > The solution would be to add symlinks like all the other OSes do. But > > Theo doesn't like that. > > > > My recall was it was less that "Theo didn't like it" than "no one had > > actually worked out how the symlink update process would work across major > > and minor version bumps in base builds and what else needed to be adjusted > > to keep things from exploding during that", because if there's one thing > > Theo doesn't like it's "oh, something committed months ago and now embedded > > in our ecosystem means that our ABI change process NO LONGER WORKS". > > My diff just created the symlinks as part of "make install" and they > would have been included in the sets. They would actualy help with > the ABI change process because the symlinks make it much easier for > developers to reverse a major or minor bump. I ran the diff for ages, > through many major and minor bumps of base libraries. Easier for developers? major.minor exists to provide greater compatlity for old user binaries, not for the developer ABI crossing procedure.
Re: Power-up cc --print-file-name for .so names
> From: "Theo de Raadt" > Date: Mon, 14 Feb 2022 00:34:53 -0700 > > > The solution would be to add symlinks like all the other OSes do. But > > Theo doesn't like that. > > No, the problem is you add symbolic links, how long before software > ecosystems in ports choose the short names in linkage -- "because it > also works"? If they do so, all the transition benefits we have gained > from the #.# names is lost. Forever. Nope. When linking against a shared library, the full #.# name is taken from the DT_SONAME entry of the shared library and recorded as a DT_NEEDED entry in the executable. And those DT_NEEDED entries are used by the dynamic linker to lookup the shared libraries. There is a scenario where this goes wrong. If a shared library lacks a DT_SONAME entry, the library filename is used to generate the DT_NEEDED entries. But I would consider such a shared library broken and we fixed base a lng time ago. Some care has to be taken when adding the symlinks to shared libraries in ports. But I'm sure the package management stuff could check that shared libraries in ports have a DT_SONAME entry. > Then, when we do the ABI breaks we are famous for, people will get screwed > because their existing binaries will load the new libraries because such > a binary will say "libc.so", and it will not load the actual library version > it was originally linked against. And therefore, the binary won't run. > > And the next step will be that internal discouragment against ABI breaks > will grow > > So it isn't that I am unhappy about it, I am just thinking ahead that > moving away from major.minor even in small steps will hurt us very badly. This will not move us away from major.minor.
Re: Power-up cc --print-file-name for .so names
> From: Philip Guenther > Date: Sun, 13 Feb 2022 23:29:06 -0800 > > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis > wrote: > > > From: Greg Steuck > > Date: Sun, 13 Feb 2022 22:37:13 -0800 > > > > To give a sense of the kind of change required to get the feature I > > want, see the patch at the end. The change in DriverUtils.cpp is just > to > > show that the same function is hiding in there. > > > > If this looks like a good direction, I can cleanup the code and maybe > it > > could be shared, though I'm not sure where this would belong. Maybe a > > new tiny library of such wrappers to maintain in our tree? > > > > Thanks > > Greg > > > > P.S. Naturally, once I install this patched cc, ghci is suddenly very > > happy. > > Something like this was rejected upstream. > > The solution would be to add symlinks like all the other OSes do. But > Theo doesn't like that. > > My recall was it was less that "Theo didn't like it" than "no one had > actually worked out how the symlink update process would work across major > and minor version bumps in base builds and what else needed to be adjusted > to keep things from exploding during that", because if there's one thing > Theo doesn't like it's "oh, something committed months ago and now embedded > in our ecosystem means that our ABI change process NO LONGER WORKS". My diff just created the symlinks as part of "make install" and they would have been included in the sets. They would actualy help with the ABI change process because the symlinks make it much easier for developers to reverse a major or minor bump. I ran the diff for ages, through many major and minor bumps of base libraries. > So, IMHO, what is needed is for someone to camp out and watch for a diff > floated that will require a major bump *and that will affect stuff run > during the base build!* and then > 1) apply the symlink changes that *seem* fine, and build some dependent > ports, > 2) apply the major bump diff > 3) build base > 4) verify whether anything exploded in the base build and if so, what/why > 5) so, do those ports still work, or do they explode until an update to them > is pushed? That all works fine. What wasn't fully sorted out is how shared libraries in ports would be handled. Most of them could probably be handled by our version of libtool, and in some other cases we could drop some of the patches. But some of the ports would need some work.
Re: Power-up cc --print-file-name for .so names
"Theo de Raadt" writes: > Philip Guenther wrote: > >> On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis >> wrote: >> >> > > From: Greg Steuck >> > > Date: Sun, 13 Feb 2022 22:37:13 -0800 >> > > >> > > To give a sense of the kind of change required to get the feature I >> > > want, see the patch at the end. The change in DriverUtils.cpp is just to >> > > show that the same function is hiding in there. >> > > >> > > If this looks like a good direction, I can cleanup the code and maybe it >> > > could be shared, though I'm not sure where this would belong. Maybe a >> > > new tiny library of such wrappers to maintain in our tree? >> > > >> > > Thanks >> > > Greg >> > > >> > > P.S. Naturally, once I install this patched cc, ghci is suddenly very >> > > happy. >> > >> > Something like this was rejected upstream. > > Upstreams are just jealous of our ABI cranking secret power. > > Why can't we carry a diff for this? Considering we already do such versioned lookup in `ld -l`, I don't anticipate considerable harm from allowing `cc --print-file-name` to have the similar power. For giggles I searched Debian sources, the literal combination that I'm planning to enhance is pretty rare[1]. One extra somebody might want is extending gcc on non-clang platforms to have consistent behavior. Since GHC isn't ported to them anyway, I don't have the immediate need to make the change. [1] https://codesearch.debian.net/search?q=--print-file-name.*lib.*so Thanks Greg
Re: Power-up cc --print-file-name for .so names
Philip Guenther wrote: > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis > wrote: > > > > From: Greg Steuck > > > Date: Sun, 13 Feb 2022 22:37:13 -0800 > > > > > > To give a sense of the kind of change required to get the feature I > > > want, see the patch at the end. The change in DriverUtils.cpp is just to > > > show that the same function is hiding in there. > > > > > > If this looks like a good direction, I can cleanup the code and maybe it > > > could be shared, though I'm not sure where this would belong. Maybe a > > > new tiny library of such wrappers to maintain in our tree? > > > > > > Thanks > > > Greg > > > > > > P.S. Naturally, once I install this patched cc, ghci is suddenly very > > > happy. > > > > Something like this was rejected upstream. Upstreams are just jealous of our ABI cranking secret power. Why can't we carry a diff for this? It is the way it works here. There is no single libc.so, there is a historical chain of them as we move forward time. One cannot point a singular symbolic link at a random libc.so.#.# and expect that noone in the downstream won't start capitalizatin on this to the disadvantage of our developers and users. There are people with machines which have 20+ libc.so.#.# shared libraries, and such systems potentially having some binaries which depend upon a specific ABI reflected in the libc.so.#.# they are directly linked against. Having that many is not normal outside of development machines, but even non-developers who have run sysugprade a few times may have them, and yet, also also have handcompiled binaries lying around which depend upon a specific ABI. And some of those will be built using toolchains which I will bet money will rapidly shift towards removing the .#.# suffixed in their link phases, and screw those users. Then those users will suggest we should never change the ABI AGAIN. lib*.so symbolic links will hurt us far more than the small gain.
Re: Power-up cc --print-file-name for .so names
Philip Guenther wrote: > Those of long memory will recall a hackathon where dependencies on libc > were put in place, the libm vs libc deps were changed as functions were > moved from libm to libc, and base builds completely broke. My recall is > that the diffs had to basically be unrolled to restore base builds to > operation, and then the libm to libc stuff was redone, but I may be > repressing memories. Bunch of us lost roughly a week of our lives.
Re: Power-up cc --print-file-name for .so names
> The solution would be to add symlinks like all the other OSes do. But > Theo doesn't like that. No, the problem is you add symbolic links, how long before software ecosystems in ports choose the short names in linkage -- "because it also works"? If they do so, all the transition benefits we have gained from the #.# names is lost. Forever. Then, when we do the ABI breaks we are famous for, people will get screwed because their existing binaries will load the new libraries because such a binary will say "libc.so", and it will not load the actual library version it was originally linked against. And therefore, the binary won't run. And the next step will be that internal discouragment against ABI breaks will grow So it isn't that I am unhappy about it, I am just thinking ahead that moving away from major.minor even in small steps will hurt us very badly.
Re: Power-up cc --print-file-name for .so names
On Sun, Feb 13, 2022 at 11:29 PM Philip Guenther wrote: > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis > wrote: > >> > From: Greg Steuck >> > Date: Sun, 13 Feb 2022 22:37:13 -0800 >> > >> > To give a sense of the kind of change required to get the feature I >> > want, see the patch at the end. The change in DriverUtils.cpp is just to >> > show that the same function is hiding in there. >> > >> > If this looks like a good direction, I can cleanup the code and maybe it >> > could be shared, though I'm not sure where this would belong. Maybe a >> > new tiny library of such wrappers to maintain in our tree? >> > >> > Thanks >> > Greg >> > >> > P.S. Naturally, once I install this patched cc, ghci is suddenly very >> > happy. >> >> Something like this was rejected upstream. >> >> The solution would be to add symlinks like all the other OSes do. But >> Theo doesn't like that. >> > > My recall was it was less that "Theo didn't like it" than "no one had > actually worked out how the symlink update process would work across major > and minor version bumps in base builds and what else needed to be adjusted > to keep things from exploding during that", because if there's one thing > Theo doesn't like it's "oh, something committed months ago and now embedded > in our ecosystem means that our ABI change process NO LONGER WORKS". > > So, IMHO, what is needed is for someone to camp out and watch for a diff > floated that will require a major bump *and that will affect stuff run > during the base build!* and then > 1) apply the symlink changes that *seem* fine, and build some dependent > ports, > 2) apply the major bump diff > 3) build base > 4) verify whether anything exploded in the base build and if so, what/why > 5) so, do those ports still work, or do they explode until an update to > them is pushed? > Those of long memory will recall a hackathon where dependencies on libc were put in place, the libm vs libc deps were changed as functions were moved from libm to libc, and base builds completely broke. My recall is that the diffs had to basically be unrolled to restore base builds to operation, and then the libm to libc stuff was redone, but I may be repressing memories. Philip
Re: Power-up cc --print-file-name for .so names
Mark Kettenis writes: >> From: Greg Steuck >> Date: Sun, 13 Feb 2022 22:37:13 -0800 >> >> To give a sense of the kind of change required to get the feature I >> want, see the patch at the end. The change in DriverUtils.cpp is just to >> show that the same function is hiding in there. >> >> If this looks like a good direction, I can cleanup the code and maybe it >> could be shared, though I'm not sure where this would belong. Maybe a >> new tiny library of such wrappers to maintain in our tree? >> >> Thanks >> Greg >> >> P.S. Naturally, once I install this patched cc, ghci is suddenly very >> happy. > > Something like this was rejected upstream. We already carry a patch to pick the version for `ld -lfoo` in our tree. I'm proposing we consistently extend it to one more interface: cc --print-file-name > The solution would be to add symlinks like all the other OSes do. But > Theo doesn't like that. That's a very different discussion. Thanks Greg
Re: Power-up cc --print-file-name for .so names
On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis wrote: > > From: Greg Steuck > > Date: Sun, 13 Feb 2022 22:37:13 -0800 > > > > To give a sense of the kind of change required to get the feature I > > want, see the patch at the end. The change in DriverUtils.cpp is just to > > show that the same function is hiding in there. > > > > If this looks like a good direction, I can cleanup the code and maybe it > > could be shared, though I'm not sure where this would belong. Maybe a > > new tiny library of such wrappers to maintain in our tree? > > > > Thanks > > Greg > > > > P.S. Naturally, once I install this patched cc, ghci is suddenly very > > happy. > > Something like this was rejected upstream. > > The solution would be to add symlinks like all the other OSes do. But > Theo doesn't like that. > My recall was it was less that "Theo didn't like it" than "no one had actually worked out how the symlink update process would work across major and minor version bumps in base builds and what else needed to be adjusted to keep things from exploding during that", because if there's one thing Theo doesn't like it's "oh, something committed months ago and now embedded in our ecosystem means that our ABI change process NO LONGER WORKS". So, IMHO, what is needed is for someone to camp out and watch for a diff floated that will require a major bump *and that will affect stuff run during the base build!* and then 1) apply the symlink changes that *seem* fine, and build some dependent ports, 2) apply the major bump diff 3) build base 4) verify whether anything exploded in the base build and if so, what/why 5) so, do those ports still work, or do they explode until an update to them is pushed? Philip
Re: Power-up cc --print-file-name for .so names
> From: Greg Steuck
> Date: Sun, 13 Feb 2022 22:37:13 -0800
>
> To give a sense of the kind of change required to get the feature I
> want, see the patch at the end. The change in DriverUtils.cpp is just to
> show that the same function is hiding in there.
>
> If this looks like a good direction, I can cleanup the code and maybe it
> could be shared, though I'm not sure where this would belong. Maybe a
> new tiny library of such wrappers to maintain in our tree?
>
> Thanks
> Greg
>
> P.S. Naturally, once I install this patched cc, ghci is suddenly very
> happy.
Something like this was rejected upstream.
The solution would be to add symlinks like all the other OSes do. But
Theo doesn't like that.
> Greg Steuck writes:
>
> > Since OpenBSD always uses .so.major.minor I observe GHCi running into
> > trouble when resolving -l on its own. The way it tries to find the
> > shared object to load is by relying on `cc --print-file-name`. I see
> > this:
> > $ ghci -v -lc++
> > ...
> > Search directories (gcc):
> > *** systool:linker:
> > *** gcc:
> > cc -Wl,-z,wxneeded --print-file-name 'libc++.so'
> > !!! systool:linker: finished in 0.00 milliseconds, allocated 0.059 megabytes
> > *** systool:linker:
> > *** gcc:
> > cc -Wl,-z,wxneeded --print-file-name 'liblibc++.so'
> > !!! systool:linker: finished in 0.00 milliseconds, allocated 0.054 megabytes
> > *** systool:linker:
> > *** gcc:
> > cc -Wl,-z,wxneeded --print-file-name 'c++.lib'
> >
> > Which never succeeds, because the only way this could work is if ghc
> > knew the version number:
> > % cc --print-file-name 'libc++.so.9.0'
> > /usr/lib/libc++.so.9.0
> >
> > It feels like I need to somehow convince cc --print-file-name to get in
> > here:
> > ports/devel/llvm/patches/patch-tools_lld_ELF_DriverUtils_cpp
> >
> > Would it be a good idea to extend clang's --print-file-name in such a
> > way that both versioned and unversioned variations work? I.e. make the
> > second command works the same as the first one below?
> >
> > % cc --print-file-name libc++.so.9.0
> > /usr/lib/libc++.so.9.0
> > % cc --print-file-name libc++.so
> > libc++.so
> >
> > Thanks
> > Greg
>
> >From 825207a1ec5b0f0941bf5a624a862c9f460ddf94 Mon Sep 17 00:00:00 2001
> From: Greg Steuck
> Date: Sun, 13 Feb 2022 22:28:43 -0800
> Subject: [PATCH] Find --print-file-name versioned lib.so's for the given short
> name
>
> This is a complement of the major.minor finding logic in DriverUtils.
> To make things more obviously related the same code was extracted into
> a function which was copied modulo namespaces and minor parameter
> adjustments
> ---
> gnu/llvm/clang/lib/Driver/Driver.cpp | 54 --
> gnu/llvm/lld/ELF/DriverUtils.cpp | 57 +++-
> 2 files changed, 82 insertions(+), 29 deletions(-)
>
> diff --git a/gnu/llvm/clang/lib/Driver/Driver.cpp
> b/gnu/llvm/clang/lib/Driver/Driver.cpp
> index 94a7553e273..cdf95ac6c9f 100644
> --- a/gnu/llvm/clang/lib/Driver/Driver.cpp
> +++ b/gnu/llvm/clang/lib/Driver/Driver.cpp
> @@ -5089,7 +5089,50 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
> const JobAction &JA,
>}
> }
>
> +
> +namespace {
> +static Optional findFile(StringRef path1, const Twine &path2) {
> + SmallString<128> s;
> + llvm::sys::path::append(s, path1, path2);
> +
> + if (llvm::sys::fs::exists(s))
> +return std::string(s);
> + return None;
> +}
> +
> +llvm::Optional findMajMinShlib(StringRef dir, StringRef
> libNameSo) {
> + // Handle OpenBSD-style maj/min shlib scheme
> + llvm::SmallString<128> Scratch;
> + const StringRef LibName = (libNameSo + ".").toStringRef(Scratch);
> + int MaxMaj = -1, MaxMin = -1;
> + std::error_code EC;
> + for (llvm::sys::fs::directory_iterator LI(dir, EC), LE;
> + LI != LE; LI = LI.increment(EC)) {
> +StringRef FilePath = LI->path();
> +StringRef FileName = llvm::sys::path::filename(FilePath);
> +if (!(FileName.startswith(LibName)))
> + continue;
> +std::pair MajMin =
> + FileName.substr(LibName.size()).split('.');
> +int Maj, Min;
> +if (MajMin.first.getAsInteger(10, Maj) || Maj < 0)
> + continue;
> +if (MajMin.second.getAsInteger(10, Min) || Min < 0)
> + continue;
> +if (Maj > MaxMaj)
> + MaxMaj = Maj, MaxMin = Min;
> +if (MaxMaj == Maj && Min > MaxMin)
> + MaxMin = Min;
> + }
> + if (MaxMaj >= 0)
> +return findFile(dir, LibName + Twine(MaxMaj) + "." + Twine(MaxMin));
> + return None;
> +}
> +
> +}
> +
> std::string Driver::GetFilePath(StringRef Name, const ToolChain &TC) const {
> + const bool lookForLibDotSo = Name.startswith("lib") &&
> Name.endswith(".so");
>// Search for Name in a list of paths.
>auto SearchPaths = [&](const llvm::SmallVectorImpl &P)
>-> llvm::Optional {
> @@ -5099,9 +5142,14 @@ std::string Driver::GetFilePath(StringRef Name, const
> ToolChain &TC) const {
>if (Dir.empty())
> continue;
>SmallString<128> P(Dir[0] == '=' ? Sy
Re: Power-up cc --print-file-name for .so names
To give a sense of the kind of change required to get the feature I
want, see the patch at the end. The change in DriverUtils.cpp is just to
show that the same function is hiding in there.
If this looks like a good direction, I can cleanup the code and maybe it
could be shared, though I'm not sure where this would belong. Maybe a
new tiny library of such wrappers to maintain in our tree?
Thanks
Greg
P.S. Naturally, once I install this patched cc, ghci is suddenly very
happy.
Greg Steuck writes:
> Since OpenBSD always uses .so.major.minor I observe GHCi running into
> trouble when resolving -l on its own. The way it tries to find the
> shared object to load is by relying on `cc --print-file-name`. I see
> this:
> $ ghci -v -lc++
> ...
> Search directories (gcc):
> *** systool:linker:
> *** gcc:
> cc -Wl,-z,wxneeded --print-file-name 'libc++.so'
> !!! systool:linker: finished in 0.00 milliseconds, allocated 0.059 megabytes
> *** systool:linker:
> *** gcc:
> cc -Wl,-z,wxneeded --print-file-name 'liblibc++.so'
> !!! systool:linker: finished in 0.00 milliseconds, allocated 0.054 megabytes
> *** systool:linker:
> *** gcc:
> cc -Wl,-z,wxneeded --print-file-name 'c++.lib'
>
> Which never succeeds, because the only way this could work is if ghc
> knew the version number:
> % cc --print-file-name 'libc++.so.9.0'
> /usr/lib/libc++.so.9.0
>
> It feels like I need to somehow convince cc --print-file-name to get in here:
> ports/devel/llvm/patches/patch-tools_lld_ELF_DriverUtils_cpp
>
> Would it be a good idea to extend clang's --print-file-name in such a
> way that both versioned and unversioned variations work? I.e. make the
> second command works the same as the first one below?
>
> % cc --print-file-name libc++.so.9.0
> /usr/lib/libc++.so.9.0
> % cc --print-file-name libc++.so
> libc++.so
>
> Thanks
> Greg
>From 825207a1ec5b0f0941bf5a624a862c9f460ddf94 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 13 Feb 2022 22:28:43 -0800
Subject: [PATCH] Find --print-file-name versioned lib.so's for the given short
name
This is a complement of the major.minor finding logic in DriverUtils.
To make things more obviously related the same code was extracted into
a function which was copied modulo namespaces and minor parameter
adjustments
---
gnu/llvm/clang/lib/Driver/Driver.cpp | 54 --
gnu/llvm/lld/ELF/DriverUtils.cpp | 57 +++-
2 files changed, 82 insertions(+), 29 deletions(-)
diff --git a/gnu/llvm/clang/lib/Driver/Driver.cpp
b/gnu/llvm/clang/lib/Driver/Driver.cpp
index 94a7553e273..cdf95ac6c9f 100644
--- a/gnu/llvm/clang/lib/Driver/Driver.cpp
+++ b/gnu/llvm/clang/lib/Driver/Driver.cpp
@@ -5089,7 +5089,50 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
const JobAction &JA,
}
}
+
+namespace {
+static Optional findFile(StringRef path1, const Twine &path2) {
+ SmallString<128> s;
+ llvm::sys::path::append(s, path1, path2);
+
+ if (llvm::sys::fs::exists(s))
+return std::string(s);
+ return None;
+}
+
+llvm::Optional findMajMinShlib(StringRef dir, StringRef
libNameSo) {
+ // Handle OpenBSD-style maj/min shlib scheme
+ llvm::SmallString<128> Scratch;
+ const StringRef LibName = (libNameSo + ".").toStringRef(Scratch);
+ int MaxMaj = -1, MaxMin = -1;
+ std::error_code EC;
+ for (llvm::sys::fs::directory_iterator LI(dir, EC), LE;
+ LI != LE; LI = LI.increment(EC)) {
+StringRef FilePath = LI->path();
+StringRef FileName = llvm::sys::path::filename(FilePath);
+if (!(FileName.startswith(LibName)))
+ continue;
+std::pair MajMin =
+ FileName.substr(LibName.size()).split('.');
+int Maj, Min;
+if (MajMin.first.getAsInteger(10, Maj) || Maj < 0)
+ continue;
+if (MajMin.second.getAsInteger(10, Min) || Min < 0)
+ continue;
+if (Maj > MaxMaj)
+ MaxMaj = Maj, MaxMin = Min;
+if (MaxMaj == Maj && Min > MaxMin)
+ MaxMin = Min;
+ }
+ if (MaxMaj >= 0)
+return findFile(dir, LibName + Twine(MaxMaj) + "." + Twine(MaxMin));
+ return None;
+}
+
+}
+
std::string Driver::GetFilePath(StringRef Name, const ToolChain &TC) const {
+ const bool lookForLibDotSo = Name.startswith("lib") && Name.endswith(".so");
// Search for Name in a list of paths.
auto SearchPaths = [&](const llvm::SmallVectorImpl &P)
-> llvm::Optional {
@@ -5099,9 +5142,14 @@ std::string Driver::GetFilePath(StringRef Name, const
ToolChain &TC) const {
if (Dir.empty())
continue;
SmallString<128> P(Dir[0] == '=' ? SysRoot + Dir.substr(1) : Dir);
- llvm::sys::path::append(P, Name);
- if (llvm::sys::fs::exists(Twine(P)))
-return std::string(P);
+ if (!lookForLibDotSo) {
+ llvm::sys::path::append(P, Name);
+ if (llvm::sys::fs::exists(Twine(P)))
+ return std::string(P);
+ } else {
+ if (auto s = findMajMinShlib(P, Name))
+ return std::string(*s);
+ }
}
return None;
};
diff --git a/gnu/llvm/lld/ELF/DriverUtils
