> From: Philip Guenther <[email protected]> > Date: Sun, 13 Feb 2022 23:29:06 -0800 > > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis <[email protected]> > wrote: > > > From: Greg Steuck <[email protected]> > > 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.
