[Bug bootstrap/105487] New: Sysroots without 32bit components cause mysterious errors

[Bug bootstrap/105487] New: Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

            Bug ID: 105487
           Summary: Sysroots without 32bit components cause mysterious
                    errors
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: psmith at gnu dot org
  Target Milestone: ---

I first reported this issue here:
https://gcc.gnu.org/pipermail/gcc/2020-August/233361.html
I said I would file a bug but I don't see any evidence that I ever did so.

It's still present in GCC 11.3.  It actually isn't limited to bootstrap,
either: if you set to a sysroot that doesn't contain any 32bit values, and thus
doesn't contain the /sysroot/usr/lib directory at all but only has
/sysroot/usr/lib64, then you can't compile GCC itself against that sysroot and,
if you have a built GCC, you can't compile programs against that sysroot.

I have hacked a workaround by creating an empty /sysroot/usr/lib directory in
my sysroot, but it took me the better part of a day to figure out the
problem... even though I had already figured this out less than two years ago. 
It would be nice to avoid the problem.

While building GCC, you will get this relatively obscure error trying to build
libgcc_s.so:

    ld: error: cannot open crti.o: No such file or directory
    ld: error: cannot open crtn.o: No such file or directory
    ld: error: cannot find -lc

If you debug it, you'll see that /sysroot/usr/lib64/crti.o does exist (same
with the others) so you will be confused.  If you look more carefully and add
-v to see search paths, you'll find that the path we use to locate 64bit
content is a relative path to the /sysroot/usr/lib directory:

   ... -L/sysroot/usr/lib/../lib64

instead using the direct path:

   ... -L/sysroot/usr/lib64

So, if you don't HAVE a /sysroot/usr/lib directory (because you aren't
supporting 32bit builds and have no need for it) your builds will fail.

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #1 from Paul Smith <psmith at gnu dot org> ---
Ugh, when I wrote "doesn't contain any 32bit values" I meant "doesn't contain
any 32bit files".

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I don't think there is anything GCC can do here really. If you don't have a
correct sysroot, it is not a GCC bug. Requring usr/lib is because all
directories are relative to that directory.

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #3 from Paul Smith <psmith at gnu dot org> ---
There's nothing "incorrect" about a sysroot that doesn't have /usr/lib in it. 
If you have a 64bit system and you don't need to run 32bit binaries, then
/usr/lib will be empty and everything will be in /usr/lib64.

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It is incorrect as that is required. Simple as that.

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
When you say "if you set to a sysroot that doesn't contain any 32bit values,
and thus doesn't contain the /sysroot/usr/lib directory at all but only has
/sysroot/usr/lib64, then you can't compile GCC itself against that sysroot" can
you
please share the way you configure GCC (sources and build tree outside of the
sysroot I presume) to compile it against such sysroot?

Just for completeness and to be able to reproduce.

While Andrew has a point, if the issue is simple enough to fix we should try.

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #6 from Paul Smith <psmith at gnu dot org> ---
If it is really required, then the GCC configure script or makefile or
something should detect this situation and fail.  There's nothing in the
current build system or documentation that says this is needed and I don't see
how any reasonable person would be expected to guess this.

My personal opinion is that it's not correct to require unwanted and
unnecessary directories to exist, just so that relative pathname lookups to
completely unrelated directories can succeed.

Here's how to reproduce:

* Create an empty directory.
* Obtain the necessary 64bit library packages (for example, the 64bit versions
of glibc / glibc-common / glibc-devel / glibc-headers / libgcc RPMs from a
CentOS repository--you might need kernel-headers too).
* Unpack them into the empty directory (for example, using rpm2cpio).
* Build GCC with that directory as the sysroot.
* Witness failure.

The 64bit library RPMs do not (as they shouldn't!) create or put any content
into the /usr/lib directory, so it won't exist in your sysroot.  In order to
have <sysroot>/usr/lib show up, you have to either install the 32bit library
packages, which we don't want or need, or else understand enough about what's
going on to create that directory by hand (and dump a ".keep" file or something
in it to be sure that empty directory pruning doesn't delete it again).

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #7 from Paul Smith <psmith at gnu dot org> ---
Just to be clear when I say "Build GCC with that directory as the sysroot" I
mean something like this:

  ../gcc-11.3.0/configure --with-sysroot=/sysroot ...

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I expect you'd also see this issue with build-many-glibcs.py (from glibc) 
if you remove the workaround code in that script:

        # GCC uses paths such as lib/../lib64, so make sure lib
        # directories always exist.
        mkdir_cmd = ['mkdir', '-p',
                     os.path.join(policy.installdir, 'lib')]
        if policy.use_usr:
            mkdir_cmd += [os.path.join(policy.installdir, 'usr', 'lib')]
        cmdlist.add_command('mkdir-lib', mkdir_cmd)

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487

--- Comment #9 from Paul Smith <psmith at gnu dot org> ---
Just to note, there are similar needs for empty directories in the GCC
installation itself; for example in a GCC install of a 64bit compiler without
32bit support this directory will be created by the installer:

    unknown/x86_64-unknown-linux-gnu/lib

which will be empty.  GCC searches paths that are relative to this directory,
as in:

   
unknown/bin/../lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/

Note how this uses x86_64-unknown-linux-gnu/lib/../lib64 so if that empty lib
directory is not present, this path cannot be found and linking will fail.

While it is true that the GCC install creates that empty directory, if you
store the compiler in a facility that doesn't preserve empty directories (like
git) they will disappear.

Of course this can be worked around by creating a temp file in empty
directories and since the empty directories ARE created as part of the compiler
install this is not really a bug; it's just a slightly surprising annoyance
that has to be kept in mind.  It would be better (IMO) if GCC used resolved
paths here as well.