On Mon, Aug 4, 2025, at 4:02 PM, Joseph Myers wrote:
> 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.
OK fair enough.
> > 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).
What's the runtime one for? RPATH and friends?
> > 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.
OK so it sounds like a first step might be to find some other change we agree
on, and build momentum from there.
Maybe the top srcdir example above is a place to begin? I saw lots of raw
"${srcdir}/.." in the libgcc build system, and by contrast `libgcc_topdir` is
barely used. Some of the flag variables mentioned there only seems defined in
select few projects, too. This makes me suspect most of those branches might be
dead code.
Let me know, and if so, I can make a new patch removing them. Maybe after a
couple rounds of that we'll have "decluttered the workbench", so to speak.
> 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.
(Somewhat an aside given my offer above to build consensus with a different
change first.)
Does a library use multiple of these **at the same time**? So far, in the
libraries we've packaged in Nixpkgs in our GCC NG work, I have not seen that.
If it's just a matter of making sure that right variation is used in various
cases, I think the outer build system can still handle this fine with the stock
variables. If there is a genuine need for more parameters (because things vary
independently), then the inner build system would keep such variables as
parameters for the outer build system.
(The closest thing I've seen to a special case is how the target-specific
headers of libstdc++ are handled.)
John
