[musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains

[Michael Forney <mforney@mforney.org>]

On 2020-03-22, Michael Forney <mforney@mforney.org> wrote:
> Hi,
>
> Resending this patch because this is still an issue, and I realized
> that the usr -> . symlink could also be removed in the build sysroot.
> Anyone who has built a native toolchain with musl-cross-make has
> probably run into this and worked around it by creating a usr -> .
> symlink in the install directory manually.
>
> To demonstrate that this only currently works by accident with
> cross-compilers, I'll start with current musl-cross-make master,
> and override the sysroot to something else:
>
> $ make TARGET=aarch64-linux-musl SYSROOT=/something-else install
> <snip>
> $ echo '#include <stdlib.h>' | ./output/bin/aarch64-linux-musl-gcc -v -x c
> -
> <snip>
> ignoring nonexistent directory
> "/tmp/musl-cross-make/output/bin/../something-else/usr/local/include"
> ignoring duplicate directory
> "/tmp/musl-cross-make/output/bin/../lib/gcc/../../lib/gcc/aarch64-linux-musl/9.2.0/../../../../aarch64-linux-musl/include"
> ignoring nonexistent directory
> "/tmp/musl-cross-make/output/bin/../something-else/usr/include"
> ignoring duplicate directory
> "/tmp/musl-cross-make/output/bin/../lib/gcc/../../lib/gcc/aarch64-linux-musl/9.2.0/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /tmp/musl-cross-make/output/bin/../lib/gcc/aarch64-linux-musl/9.2.0/../../../../aarch64-linux-musl/include
> /tmp/musl-cross-make/output/bin/../lib/gcc/aarch64-linux-musl/9.2.0/include
> End of search list.
> GNU C17 (GCC) version 9.2.0 (aarch64-linux-musl)
>         compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version
> 4.0.2, MPC version 1.1.0, isl version none
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> Compiler executable checksum: 32e14193b549d09fa3807c50f194d659
> <stdin>:1:10: fatal error: stdlib.h: No such file or directory
> compilation terminated.
> $
>
> As you can see, gcc *is* searching for headers in the /something-else
> sysroot, but under the incorrect system header directory. It still
> searches for headers in /aarch64-linux-musl/include since that is
> the gcc tool directory.
>
> To demonstrate the problem with native toolchains, let's build a
> native toolchain and try to use it:
>
> $ make TARGET=x86_64-linux-musl NATIVE=1 install
> <snip>
> $ echo '#include <stdlib.h>' | ./output-x86_64-linux-musl/bin/gcc -v -x c -
> <snip>
> ignoring nonexistent directory
> "/tmp/musl-cross-make/output-x86_64-linux-musl/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/include"
> ignoring nonexistent directory
> "/tmp/musl-cross-make/output-x86_64-linux-musl/bin/../usr/local/include"
> ignoring nonexistent directory
> "/tmp/musl-cross-make/output-x86_64-linux-musl/bin/../lib/gcc/../../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/include"
> ignoring nonexistent directory
> "/tmp/musl-cross-make/output-x86_64-linux-musl/bin/../usr/include"
> ignoring duplicate directory
> "/tmp/musl-cross-make/output-x86_64-linux-musl/bin/../lib/gcc/../../lib/gcc/x86_64-linux-musl/9.2.0/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /tmp/musl-cross-make/output-x86_64-linux-musl/bin/../lib/gcc/x86_64-linux-musl/9.2.0/include
> End of search list.
> GNU C17 (GCC) version 9.2.0 (x86_64-linux-musl)
>         compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version
> 4.0.2, MPC version 1.1.0, isl version none
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> Compiler executable checksum: 60320f85342923d8a86b40331aa7a54b
> <stdin>:1:10: fatal error: stdlib.h: No such file or directory
> compilation terminated.
> $
>
> With the proposed patch, both of these cases are fixed. Hopefully
> this makes the problem clear.

Hi Rich,

When I mentioned this patch on IRC, you expressed some concern that
you didn't think --with-native-system-header-dir was relevant for
cross compilers. However, I think I have made a pretty good case here
showing that it is, and that the default value of /usr/include is not
correct.

If you still have concerns, could you please let me know so I can try
to address them?

Thanks,

Michael