On Sun, 3 Aug 2025, John Ericson wrote: > > and "get those settings passed down from top level" is one plausible > > end state - sharing logic implicitly that way rather than expanding it > > all locally in each target library configure script, even if expanding > > it locally for each library is useful as an intermediate stage.) > > Correct me if I am wrong, but this is you agreeing with the end state I > had in mind from above, at least as one possible outcome? (I am not sure > how much your concerns are over the just intermediate state, or also the > end state.) (See below also on this.)
I'm reserving judgement on the end state. > But, doing that means that all the various built-in logic that comes > with Autotools around libdir, includedir etc. can no longer be taken > advantaged of so easily. Also, it would be misleading for my use-case That's unavoidable to some extent, given that the GCC libraries have additional concepts for installation directories (such as a directory for shared libgcc used at runtime separate from directories used at compile time). > I would hope instead that since GCC has already "crossed the Rubicon" of > having runtime lib host = overall target, we can just solve any > confusion by expanding the existing docs on that to cover these new > cases, and citing those docs vigorously. I would be happy to do that. My thought is that defining terminology for the various directories, and ensuring common code is used to work with them, should come first, before any rearrangement of where the directories get computed when GCC is built. Note for example that as well as the different kinds of library directory, library directories can get different kinds of multilib suffix added; some get the output of -print-multi-os-directory (e.g. ../lib64) added, others get the output of -print-multi-directory (e.g. 64). So the terminology needs to be clear about what refers to a directory with or without multilib suffix, and what kind of suffix. It's also necessary to allow for --enable-version-specific-runtime-libs. -- Joseph S. Myers josmy...@redhat.com
