Philip Guenther <guent...@gmail.com> wrote: > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis <mark.kette...@xs4all.nl> > wrote: > > > > From: Greg Steuck <gne...@openbsd.org> > > > 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.
