Re: cross-toolchain build issue with lib vs. lib64

[Szabolcs Nagy <nsz at port70 dot net>]

* Steve Ellcey <sellcey@cavium.com> [2016-12-26 10:53:01 -0800]:
> 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've run into this and i blamed the path logic in gcc.

i think installing an empty lib dir in glibc makes sense.

> 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