On Feb 21, 2024, Jason Merrill <ja...@redhat.com> wrote: > So indeed I guess we still > want both prev and current libgcc directories in RPATH to handle the > case where we've removed the previous stage, as below.
*nod*, thanks > I can't think of why we would need to depend on the current stage > target libraries, > If bootstrap doesn't actually need the target libraries. ISTM we may be miscommunicating. I'm not so worried about bootstrap itself as I am about post-bootstrap host tools. Those are unusual in that, after native bootstraps, they're built using the just-built (last-stage) compiler and target libraries, rather than the host compiler and system libraries. While configuring them, we need LD_LIBRARY_PATH (or similar) set up so that native execution tests can pass, at the very least; while building them, we may need LD_LIBRARY_PATH set up so that dependent libraries are found and link correctly. > I'm hoping for a fix that doesn't require individual users to know > about a workaround. I'm sure we'd all appreciate that, but AFAICT the conflicting requirements in scenarios of different freshness of libraries (system vs build) and both system tools and host tools dependencies on them would require a lot more intelligence in our build system to detect and react to the circumstances, deciding whether or not native tools used behind the scenes by the build will run with the just-built libraries, and whether or not the post-bootstrap host tools linked with the just-built libraries will run with the system libraries. There may even be scenarios in which these conflicting requirements would paint users into an inescapable corner AFAICT. The most worrying aspect is not libstdc++, but libgcc_s; it's needed as a dynamic library by languages that support exceptions, and depending on relative freshness of the toolchain being built and system libraries, newer symbols may be required by system programs and by just-built host tools. There doesn't seem to be an easy way around that. You have to either privilege one scenario over the other, like we do now, or introduce cleverness to detect and cope with such conflicting requirements, which we're not even trying to do. The approach in your patch changes the situation from privileging one scenario to privileging a mixed scenario (just-built libgcc but system libstdc++), and I'm pretty sure hunch that this mixed approach is likely to break down the road, even if not right now. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
