On Tue, Aug 5, 2025, at 5:15 PM, Joseph Myers wrote:
> On Tue, 5 Aug 2025, John Ericson wrote:
>
> > > 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 think RPATH should generally be discouraged, and slibdir (as configured
> using --with-slibdir=) reflects configurations where e.g. shared libgcc
> goes in /lib but shared libstdc++ and other libraries go in /usr/lib.
> (Nowadays those tend to be the same directory on GNU/Linux systems.)
Ah OK. `--with-slibdir` is fine with me. Basically, when the name of the
parameter makes sense as "what it is fine" not "what the argument happens to
be", I am OK with this. `slibdir` I take it is something like "shared libs
directory", which....is fine.
> > 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.
>
> I'm not sure source directory references have that much relevance to
> cleaning up installation directory references, but I certainly expect
> there's scope for such cleanup.
So I went ahead a taking a stab at it with
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/691963.html That patch
might be a no-go, in which case I'll learn something useful about how multilib
works, or it might be fine, in which case I can keep hunting for dead variables
to "clear the workbench". Good either way.
It is indeed only tangentially related, but it does also approach the question
of what the division of labor between the inner project config logic and outer
build system logic should be. The two areas have that in common, at least.
Also I posted (3 years later) a new version of the patches I made for the
compiler itself.
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/691964.html These are
needed to make the -B... flags our wrapper script is adding work properly
without jumping through extra hoops. The wrapper script will do that either
way, but thematic connection is that in general with Nix our approach is
• packages always install to disjoint directories, each package layouts should
be like "simplified" unix files systems with just .../lib, .../include, no
/usr, /opt, funny, subdirs, or other oddities. Since packages should "do one
thing and do it well", we don't need the other dirs.
• "late binding" (like with the wrapper scripts and -B....) allows us to embed
as few assumptions as possible at build time about what packages use what other
packages, minimizing rebuilds.
The libdir reworking and -B... functionality together support the above
objectives.
Unlike the first patch (but like the original thread's patch), the second patch
series is used today in our GCC NG patches, so I feel a bit more responsibility
to get it upstreamed.
Cheers,
John
