cross-toolchain build issue with lib vs. lib64

[Steve Ellcey]

I have run into an interesting cross-toolchain build issue.  I was building
a cross toolchain targeting aarch64 and when building the second GCC (after
building glibc and installing it in a sysroot), the build was failing because
the new gcc could not find crti.o.  I compared what I was doing with what
the build-many-glibcs.py script was doing and found that after that script
built and installed glibc it did a mkdir of $SYSROOT/usr/lib which was not
created by the glibc install because the install put everything in
$SYSROOT/usr/lib64.

$SYSROOT/usr/lib is needed (even when empty) because the library search path
used by GCC includes $SYSROOT/usr/lib/../lib64 and if lib does not exist this
search does not find things in lib64.

I thought about having GCC create this directory since it is the one using
the 'strange' path, but normally a GCC build/install would not do anything
in $SYSROOT so I don't think that would be a good idea.

So the only alternative to the current workaround seems to be to have the
GLIBC install create a lib directory even if it doesn't put anything in it.
Does that seem like a reasonable thing to do?

The existing workaround of doing a mkdir after the build and install of
glibc is simple but I have a general dislike of having to do anything other
than 'configure/make/make install' when building so I would like to see the
actual 'make install' in glibc do this step automatically.

I don't have a patch at this point, the glibc Makefile/Makeconfig/Makerules
setup is pretty complicated and I am still trying to figure out how and where
this should be done, so if anyone has any ideas on how or where this mkdir
should go that would be helpful too if this is something that we agree should
be done.

Steve Ellcey
sellcey@caviumnetworks.com