mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl-cross-make] [PATCH] litecross: Fix system header dir when building native toolchains
@ 2018-11-07  6:49 Michael Forney
  2020-03-23  4:34 ` [musl] [musl-cross-make] [PATCH v2] " Michael Forney
  0 siblings, 1 reply; 15+ messages in thread
From: Michael Forney @ 2018-11-07  6:49 UTC (permalink / raw)
  To: musl

By default, gcc will search in /usr/include relative to the sysroot,
but musl is configured with an empty prefix, so headers get installed
to /include. This causes gcc to fail to find the libc headers unless
a usr -> . symlink is created manually.

This is not an issue for cross toolchains because in that case, the
configured sysroot is /$(TARGET) which happens to match gcc_tooldir[0],
which is one of gcc's default search directories[1].

The system header directory can be configured with
--with-native-system-header-dir. However, this is not quite sufficient
because the stmp-fixinc target in gcc/Makefile tests for the existence
of that directory relative to the configured sysroot (/)[2]. Most
systems do not have /include, so this fails.

Since musl's fixinc.sh is a no-op[3], we can work around this by
clearing STMP_FIXINC, skipping fixincludes entirely.

[0] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=b066cc609e1c2615e66307d5439f765a4f3b286b;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l6319
[1] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/linux.h;h=2ea4ff92c1df9e6d6297996004360ae7eeda2075;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l180
[2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/Makefile.in;h=20bee0494b1bad4e3ec34e2eae291cf6eadc3aa1;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l3078
[3] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=fixincludes/mkfixinc.sh;h=0f9648608e94f97ab13da223d8192cb04c255772;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l22
---
 litecross/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/litecross/Makefile b/litecross/Makefile
index 2f78157..d1e52b6 100644
--- a/litecross/Makefile
+++ b/litecross/Makefile
@@ -55,6 +55,7 @@ MAKE += MULTILIB_OSDIRNAMES=
 MAKE += INFO_DEPS= infodir=
 MAKE += ac_cv_prog_lex_root=lex.yy.c
 MAKE += MAKEINFO=false
+MAKE += STMP_FIXINC=
 
 FULL_BINUTILS_CONFIG = \
 	$(COMMON_CONFIG) $(BINUTILS_CONFIG) $(TOOLCHAIN_CONFIG) \
@@ -70,6 +71,7 @@ FULL_GCC_CONFIG = --enable-languages=c,c++ \
 	--target=$(TARGET) --prefix= \
 	--libdir=/lib --disable-multilib \
 	--with-sysroot=$(SYSROOT) \
+	--with-native-system-header-dir=/include \
 	--enable-tls \
 	--disable-libmudflap --disable-libsanitizer \
 	--disable-gnu-indirect-function \
-- 
2.19.1



^ permalink raw reply	[flat|nested] 15+ messages in thread

* [musl] [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2018-11-07  6:49 [musl-cross-make] [PATCH] litecross: Fix system header dir when building native toolchains Michael Forney
@ 2020-03-23  4:34 ` Michael Forney
  2020-05-09  0:27   ` [musl] " Michael Forney
  0 siblings, 1 reply; 15+ messages in thread
From: Michael Forney @ 2020-03-23  4:34 UTC (permalink / raw)
  To: musl

By default, gcc will search in /usr/include relative to the sysroot,
but musl is configured with an empty prefix, so headers get installed
to /include. This causes gcc to fail to find the libc headers for
native toolchains unless a usr -> . symlink is created manually.

This is not an issue for cross toolchains because in that case, the
configured sysroot is /$(TARGET) which happens to match gcc_tooldir[0],
which is one of gcc's default search directories[1].

The system header directory can be configured with
--with-native-system-header-dir. However, this is not quite sufficient
because the stmp-fixinc target in gcc/Makefile tests for the existence
of that directory relative to the configured sysroot (/)[2]. Most
systems do not have /include, so this fails.

Since musl's fixinc.sh is a no-op[3], we can work around this by
clearing STMP_FIXINC, skipping fixincludes entirely.

This removes the need for creating the usr -> . symlink in the build
sysroot, and having to manually create this symlink for native
toolchains (as in [4]).

[0] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=b066cc609e1c2615e66307d5439f765a4f3b286b;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l6319
[1] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/linux.h;h=2ea4ff92c1df9e6d6297996004360ae7eeda2075;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l180
[2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/Makefile.in;h=20bee0494b1bad4e3ec34e2eae291cf6eadc3aa1;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l3078
[3] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=fixincludes/mkfixinc.sh;h=0f9648608e94f97ab13da223d8192cb04c255772;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l22
[4] https://git.zv.io/toolchains/musl-cross-make/-/blob/5774ca4dc5bdb813e33052023d982ee073a5c6b8/scripts/buildall#L30
---
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.

 litecross/Makefile | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/litecross/Makefile b/litecross/Makefile
index 8ec0ed2..11ef946 100644
--- a/litecross/Makefile
+++ b/litecross/Makefile
@@ -55,6 +55,7 @@ MAKE += MULTILIB_OSDIRNAMES=
 MAKE += INFO_DEPS= infodir=
 MAKE += ac_cv_prog_lex_root=lex.yy
 MAKE += MAKEINFO=false
+MAKE += STMP_FIXINC=
 
 FULL_BINUTILS_CONFIG = \
 	--disable-separate-code \
@@ -74,6 +75,7 @@ FULL_GCC_CONFIG = --enable-languages=c,c++ \
 	--target=$(TARGET) --prefix= \
 	--libdir=/lib --disable-multilib \
 	--with-sysroot=$(SYSROOT) \
+	--with-native-system-header-dir=/include \
 	--enable-tls \
 	--disable-libmudflap --disable-libsanitizer \
 	--disable-gnu-indirect-function \
@@ -112,7 +114,7 @@ FULL_MUSL_CONFIG += CC="$(XGCC)" LIBCC="../obj_gcc/$(TARGET)/libgcc/libgcc.a"
 MUSL_VARS = AR=../obj_binutils/binutils/ar RANLIB=../obj_binutils/binutils/ranlib
 obj_musl/.lc_configured: | obj_gcc/gcc/.lc_built
 obj_musl/.lc_built: | obj_gcc/$(TARGET)/libgcc/libgcc.a
-obj_gcc/gcc/.lc_built: | obj_sysroot/usr obj_sysroot/lib32 obj_sysroot/lib64 obj_sysroot/include
+obj_gcc/gcc/.lc_built: | obj_sysroot/lib32 obj_sysroot/lib64 obj_sysroot/include
 obj_gcc/.lc_built: | obj_sysroot/.lc_libs obj_sysroot/.lc_headers
 obj_gcc/.lc_configured: obj_binutils/.lc_built
 else
@@ -197,9 +199,6 @@ obj_%:
 obj_sysroot/include:
 	mkdir -p $@
 
-obj_sysroot/usr: | obj_sysroot
-	ln -sf . $@
-
 obj_sysroot/lib32: | obj_sysroot
 	ln -sf lib $@
 
-- 
2.25.2


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-03-23  4:34 ` [musl] [musl-cross-make] [PATCH v2] " Michael Forney
@ 2020-05-09  0:27   ` Michael Forney
  2020-05-10 16:35     ` Rich Felker
  0 siblings, 1 reply; 15+ messages in thread
From: Michael Forney @ 2020-05-09  0:27 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-09  0:27   ` [musl] " Michael Forney
@ 2020-05-10 16:35     ` Rich Felker
  2020-05-10 20:35       ` Michael Forney
  2020-08-19 21:00       ` Michael Forney
  0 siblings, 2 replies; 15+ messages in thread
From: Rich Felker @ 2020-05-10 16:35 UTC (permalink / raw)
  To: Michael Forney; +Cc: musl

On Fri, May 08, 2020 at 05:27:11PM -0700, Michael Forney wrote:
> 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?

Sorry I haven't had the time/attention to devote to this. I think
there's still a major mismatch in expectations -- the system you
install this native compiler onto is not going to have its include
files in /include but the standard /usr/include, among a lot of other
things. Cross-compiling a native compiler is in many ways a really
poor match for what musl-cross-make is intended to do. The "stop to
build musl in the middle" logic doesn't really even make much sense
when the target libs are being compiled by an existing cross compiler
toolchain that already has its own musl headers and libc.so.

I think you're right that we're doing something very wrong here, but I
don't understand exactly what it is, and before making changes I want
to get to the poing where we're on the same page about what it
*should* be doing. Maybe we mostly are, but I don't understand enough
yet to know whether we are.

I know there's also an issue someone (perhaps yourself; I don't
remember at the moment) brought to my attention that there's a mixup
in the logic in litecross/Makefile for "is a cross compile" vs "is
being cross compiled" that messes up completely in the canadian cross
case. This further suggests to me that there's a big mess that needs
to be unraveled..

I'll try to get back to this sometime soon, but at the moment my focus
is already split several ways between mallocng, initial entropy source
and csprng issues for musl (was considered a prereq for merging
mallocng but I think it's turning out to be mostly separate which may
mean I can punt on this for a while), bringing this all together for
next musl release, and paid work independent from musl.

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-10 16:35     ` Rich Felker
@ 2020-05-10 20:35       ` Michael Forney
  2020-05-10 21:52         ` Rich Felker
  2020-08-19 21:00       ` Michael Forney
  1 sibling, 1 reply; 15+ messages in thread
From: Michael Forney @ 2020-05-10 20:35 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

Thanks for your response, Rich.

On 2020-05-10, Rich Felker <dalias@libc.org> wrote:
> Sorry I haven't had the time/attention to devote to this. I think
> there's still a major mismatch in expectations -- the system you
> install this native compiler onto is not going to have its include
> files in /include but the standard /usr/include, among a lot of other
> things.

My understanding was that musl-cross-make toolchains (native or cross)
were meant to be self-contained units, so the include directory
relative to the sysroot is always /include.

Merging a native toolchain into / can't work, even using the default
/usr/include search directory, because you'd still have musl headers
installed into /include, so the compiler would be unable to find the
musl headers (this is the same reason why you currently need the usr
-> . symlink). To support something like this, I think you'd need to
make the prefix configurable.

> Cross-compiling a native compiler is in many ways a really
> poor match for what musl-cross-make is intended to do. The "stop to
> build musl in the middle" logic doesn't really even make much sense
> when the target libs are being compiled by an existing cross compiler
> toolchain that already has its own musl headers and libc.so.
>
> I think you're right that we're doing something very wrong here, but I
> don't understand exactly what it is, and before making changes I want
> to get to the poing where we're on the same page about what it
> *should* be doing. Maybe we mostly are, but I don't understand enough
> yet to know whether we are.
>
> I know there's also an issue someone (perhaps yourself; I don't
> remember at the moment) brought to my attention that there's a mixup
> in the logic in litecross/Makefile for "is a cross compile" vs "is
> being cross compiled" that messes up completely in the canadian cross
> case. This further suggests to me that there's a big mess that needs
> to be unraveled..

I'm sure there are other improvements that can be made, but I don't
see why those should block this change. It's pretty clear to me that
$SYSROOT/usr/include is the wrong directory to search for these
headers, since they are not installed in this location. This is backed
up by fact that litecross creates a usr -> . symlink in the sysroot,
and that you need to create this symlink manually for a native
toolchain.

Even forgetting native compilers entirely, this patch still removes a
hack for cross-compilers which only works coincidentally.

> I'll try to get back to this sometime soon, but at the moment my focus
> is already split several ways between mallocng, initial entropy source
> and csprng issues for musl (was considered a prereq for merging
> mallocng but I think it's turning out to be mostly separate which may
> mean I can punt on this for a while), bringing this all together for
> next musl release, and paid work independent from musl.

No worries, there is no rush. But keep in mind that I sent this patch
1.5 years ago (and mentioned it a couple times on IRC).

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-10 20:35       ` Michael Forney
@ 2020-05-10 21:52         ` Rich Felker
  2020-05-13  8:18           ` Michael Forney
  0 siblings, 1 reply; 15+ messages in thread
From: Rich Felker @ 2020-05-10 21:52 UTC (permalink / raw)
  To: Michael Forney; +Cc: musl

On Sun, May 10, 2020 at 01:35:23PM -0700, Michael Forney wrote:
> Thanks for your response, Rich.
> 
> On 2020-05-10, Rich Felker <dalias@libc.org> wrote:
> > Sorry I haven't had the time/attention to devote to this. I think
> > there's still a major mismatch in expectations -- the system you
> > install this native compiler onto is not going to have its include
> > files in /include but the standard /usr/include, among a lot of other
> > things.
> 
> My understanding was that musl-cross-make toolchains (native or cross)
> were meant to be self-contained units, so the include directory
> relative to the sysroot is always /include.

This is true for cross compilers, which were the original only
in-scope task of musl-cross-make. Adding NATIVE=y mode was a quick
hack that was later fleshed out somewhat, but there was never any
real design behind how it should work, and it shows. I'm not really
sure whether it should be a proper native compiler for the target, or
effectively a sysrooted self-targeting cross compiler that runs on the
target. In some sense these are two different things and the user
should be aware of which one they're requesting/getting....

> Merging a native toolchain into / can't work, even using the default
> /usr/include search directory, because you'd still have musl headers
> installed into /include, so the compiler would be unable to find the
> musl headers (this is the same reason why you currently need the usr
> -> . symlink). To support something like this, I think you'd need to
> make the prefix configurable.

I think the symlink is just missing (not done via the same rule as for
cross compilers because the sysroot base is different for a non-cross
compiler). At least relative to what I remember of my original intent.
But I'm doubtful that this was well thought out at all since the only
real intent at the time I added it was "can I make a compiler run on a
nommu j2?" where I didn't want to bootstrap a whole distro or have
anything serious actually compiled on the target where it would have
been prohibitively slow.

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-10 21:52         ` Rich Felker
@ 2020-05-13  8:18           ` Michael Forney
  2020-05-13 14:37             ` Rich Felker
  0 siblings, 1 reply; 15+ messages in thread
From: Michael Forney @ 2020-05-13  8:18 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

On 2020-05-10, Rich Felker <dalias@libc.org> wrote:
> On Sun, May 10, 2020 at 01:35:23PM -0700, Michael Forney wrote:
>> My understanding was that musl-cross-make toolchains (native or cross)
>> were meant to be self-contained units, so the include directory
>> relative to the sysroot is always /include.
>
> This is true for cross compilers, which were the original only
> in-scope task of musl-cross-make. Adding NATIVE=y mode was a quick
> hack that was later fleshed out somewhat, but there was never any
> real design behind how it should work, and it shows. I'm not really
> sure whether it should be a proper native compiler for the target, or
> effectively a sysrooted self-targeting cross compiler that runs on the
> target. In some sense these are two different things and the user
> should be aware of which one they're requesting/getting....

Again, forgetting NATIVE=1 compilers entirely, this still fixes a bug
for cross-compilers that is currently hidden by the fact that the
sysroot (/$TARGET) happens to match the gcc tool directory.

>> Merging a native toolchain into / can't work, even using the default
>> /usr/include search directory, because you'd still have musl headers
>> installed into /include, so the compiler would be unable to find the
>> musl headers (this is the same reason why you currently need the usr
>> -> . symlink). To support something like this, I think you'd need to
>> make the prefix configurable.
>
> I think the symlink is just missing (not done via the same rule as for
> cross compilers because the sysroot base is different for a non-cross
> compiler).

I don't quite understand what you mean here, or why you think a
symlink should be necessary in the first place. The sysroot base
doesn't matter here; for both native and cross toolchains,
musl-cross-make installs musl headers to $SYSROOT/include
($OUTPUT/include for native, and $OUTPUT/$TARGET/include for cross).
Currently, gcc is searching for headers in $SYSROOT/usr/include, as it
does by default, but we can configure gcc to instead search
$SYSROOT/include (where the headers actually are) by using
--with-native-system-header-dir=/include.

What I meant above is that if you were to try to merge a
musl-cross-make toolchain into /, you'd have two separate directories,
/include containing the toolchain headers, and /usr/include containing
the system library headers. gcc would only search for headers in
/usr/include, and you couldn't use a symlink since both are separate
directories with separate contents. To support this, you'd need to set
--prefix=/usr and install musl headers to $SYSROOT/usr/include, but I
think this is probably out of scope of musl-cross-make (at least, out
of scope of this patch). Also note that the proposed patch does not
conflict with a change like this, you'd just set
--with-native-system-header-dir=$(PREFIX)/include instead.

> At least relative to what I remember of my original intent.
> But I'm doubtful that this was well thought out at all since the only
> real intent at the time I added it was "can I make a compiler run on a
> nommu j2?" where I didn't want to bootstrap a whole distro or have
> anything serious actually compiled on the target where it would have
> been prohibitively slow.

I get that you're unhappy with the current state of musl-cross-make
and NATIVE=1, and sure, there are probably some improvements to be
made, but I think you're making this out to be trickier than it
actually is. Once you have time to take a closer look at this, I think
you'll find that it really is a simple issue of gcc searching the
wrong directory by default.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-13  8:18           ` Michael Forney
@ 2020-05-13 14:37             ` Rich Felker
  2020-05-13 18:48               ` Michael Forney
  0 siblings, 1 reply; 15+ messages in thread
From: Rich Felker @ 2020-05-13 14:37 UTC (permalink / raw)
  To: Michael Forney; +Cc: musl

On Wed, May 13, 2020 at 01:18:05AM -0700, Michael Forney wrote:
> On 2020-05-10, Rich Felker <dalias@libc.org> wrote:
> > On Sun, May 10, 2020 at 01:35:23PM -0700, Michael Forney wrote:
> >> My understanding was that musl-cross-make toolchains (native or cross)
> >> were meant to be self-contained units, so the include directory
> >> relative to the sysroot is always /include.
> >
> > This is true for cross compilers, which were the original only
> > in-scope task of musl-cross-make. Adding NATIVE=y mode was a quick
> > hack that was later fleshed out somewhat, but there was never any
> > real design behind how it should work, and it shows. I'm not really
> > sure whether it should be a proper native compiler for the target, or
> > effectively a sysrooted self-targeting cross compiler that runs on the
> > target. In some sense these are two different things and the user
> > should be aware of which one they're requesting/getting....
> 
> Again, forgetting NATIVE=1 compilers entirely, this still fixes a bug
> for cross-compilers that is currently hidden by the fact that the
> sysroot (/$TARGET) happens to match the gcc tool directory.
> 
> >> Merging a native toolchain into / can't work, even using the default
> >> /usr/include search directory, because you'd still have musl headers
> >> installed into /include, so the compiler would be unable to find the
> >> musl headers (this is the same reason why you currently need the usr
> >> -> . symlink). To support something like this, I think you'd need to
> >> make the prefix configurable.
> >
> > I think the symlink is just missing (not done via the same rule as for
> > cross compilers because the sysroot base is different for a non-cross
> > compiler).
> 
> I don't quite understand what you mean here, or why you think a
> symlink should be necessary in the first place. The sysroot base
> doesn't matter here; for both native and cross toolchains,
> musl-cross-make installs musl headers to $SYSROOT/include
> ($OUTPUT/include for native, and $OUTPUT/$TARGET/include for cross).

What the sysroot dir is for a cross toolchain is an implementation
detail of the cross compiler toolchain. It's not part of any larger
filesystem on the target.

For a native compiler, the include path is supposed to be the normal
native one. For a self-targeting cross compiler (one possible
interpretation of native that wasn't my intent) it's not. These should
probably be distinct supported cases.

> Currently, gcc is searching for headers in $SYSROOT/usr/include, as it
> does by default, but we can configure gcc to instead search
> $SYSROOT/include (where the headers actually are) by using
> --with-native-system-header-dir=/include.

"Where they actually are" is a mistake. There is no intent to put
/include on the target system at all. It was probably a mistake to
even make this sysrooted the way it is but I don't know the right way
to do it. Maybe it's just turning off sysroot. Toolchain headers
should be relative to the toolchain install location so that you can
install it wherever you want (/opt, /usr/local, ~, whatever) while
native system headers should be searched in the standard locations.

Again, this is for a real native compiler. Cross-to-self should be
different.

Again, it's clear that none of this was thought out when I quickly
added the option.

> I get that you're unhappy with the current state of musl-cross-make
> and NATIVE=1, and sure, there are probably some improvements to be
> made, but I think you're making this out to be trickier than it
> actually is. Once you have time to take a closer look at this, I think
> you'll find that it really is a simple issue of gcc searching the
> wrong directory by default.

No, it's a complex matter of it using the wrong paths entirely.

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-13 14:37             ` Rich Felker
@ 2020-05-13 18:48               ` Michael Forney
  2020-05-13 18:55                 ` Rich Felker
  0 siblings, 1 reply; 15+ messages in thread
From: Michael Forney @ 2020-05-13 18:48 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

On 2020-05-13, Rich Felker <dalias@libc.org> wrote:
> What the sysroot dir is for a cross toolchain is an implementation
> detail of the cross compiler toolchain. It's not part of any larger
> filesystem on the target.

All the paths I'm talking about are relative to the relocatable
sysroot. Whenever I speak of $SYSROOT, I mean the dynamically
determined sysroot path relative to the compiler binary. The larger
filesystem on the target is irrelevant here.

> For a native compiler, the include path is supposed to be the normal
> native one. For a self-targeting cross compiler (one possible
> interpretation of native that wasn't my intent) it's not. These should
> probably be distinct supported cases.

Okay, but this is not how it works currently, and does not seem to be
how people expect it to work. Both native and cross compilers search
for headers in $SYSROOT/usr/include, where $SYSROOT is determined
relative to the compiler binary. /usr/include on the actual system
root is not considered.

>> Currently, gcc is searching for headers in $SYSROOT/usr/include, as it
>> does by default, but we can configure gcc to instead search
>> $SYSROOT/include (where the headers actually are) by using
>> --with-native-system-header-dir=/include.
>
> "Where they actually are" is a mistake. There is no intent to put
> /include on the target system at all. It was probably a mistake to
> even make this sysrooted the way it is but I don't know the right way
> to do it. Maybe it's just turning off sysroot. Toolchain headers
> should be relative to the toolchain install location so that you can
> install it wherever you want (/opt, /usr/local, ~, whatever) while
> native system headers should be searched in the standard locations.

I think you are misunderstanding what the "native system header dir"
is. Here's the gcc documentation:

--with-native-system-header-dir=dirname

    Specifies that dirname is the directory that contains native system header
    files, rather than /usr/include. This option is most useful if you
are creating
    a compiler that should be isolated from the system as much as possible. It
    is most commonly used with the --with-sysroot option and will cause GCC
    to search dirname inside the system root specified by that option.

It is not relative to /, it is relative to the sysroot, which is
determined dynamically based on the location of the compiler binary.

For a cross toolchain we currently have:

gcc binary: /some/path/bin/gcc
sysroot: ../x86_64-linux-musl
native system header dir: ../x86_64-linux-musl/usr/include
musl header install directory: ../x86_64-linux-musl/include

For a native toolchain we currently have:

gcc binary: /some/path/bin/gcc
sysroot: ../
native system header dir: ../usr/include
musl header install directory: ../include

So --with-native-system-header-dir=/include will indeed search where
the headers actually are, wherever the toolchain might have been
relocated.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-13 18:48               ` Michael Forney
@ 2020-05-13 18:55                 ` Rich Felker
  2020-05-13 19:34                   ` Michael Forney
  0 siblings, 1 reply; 15+ messages in thread
From: Rich Felker @ 2020-05-13 18:55 UTC (permalink / raw)
  To: Michael Forney; +Cc: musl

On Wed, May 13, 2020 at 11:48:57AM -0700, Michael Forney wrote:
> On 2020-05-13, Rich Felker <dalias@libc.org> wrote:
> > What the sysroot dir is for a cross toolchain is an implementation
> > detail of the cross compiler toolchain. It's not part of any larger
> > filesystem on the target.
> 
> All the paths I'm talking about are relative to the relocatable
> sysroot. Whenever I speak of $SYSROOT, I mean the dynamically
> determined sysroot path relative to the compiler binary. The larger
> filesystem on the target is irrelevant here.
> 
> > For a native compiler, the include path is supposed to be the normal
> > native one. For a self-targeting cross compiler (one possible
> > interpretation of native that wasn't my intent) it's not. These should
> > probably be distinct supported cases.
> 
> Okay, but this is not how it works currently, and does not seem to be
> how people expect it to work. Both native and cross compilers search
> for headers in $SYSROOT/usr/include, where $SYSROOT is determined
> relative to the compiler binary. /usr/include on the actual system
> root is not considered.
> 
> >> Currently, gcc is searching for headers in $SYSROOT/usr/include, as it
> >> does by default, but we can configure gcc to instead search
> >> $SYSROOT/include (where the headers actually are) by using
> >> --with-native-system-header-dir=/include.
> >
> > "Where they actually are" is a mistake. There is no intent to put
> > /include on the target system at all. It was probably a mistake to
> > even make this sysrooted the way it is but I don't know the right way
> > to do it. Maybe it's just turning off sysroot. Toolchain headers
> > should be relative to the toolchain install location so that you can
> > install it wherever you want (/opt, /usr/local, ~, whatever) while
> > native system headers should be searched in the standard locations.
> 
> I think you are misunderstanding what the "native system header dir"
> is. Here's the gcc documentation:
> 
> --with-native-system-header-dir=dirname
> 
>     Specifies that dirname is the directory that contains native system header
>     files, rather than /usr/include. This option is most useful if you
> are creating
>     a compiler that should be isolated from the system as much as possible. It
>     is most commonly used with the --with-sysroot option and will cause GCC
>     to search dirname inside the system root specified by that option.
> 
> It is not relative to /, it is relative to the sysroot, which is
> determined dynamically based on the location of the compiler binary.

Yes, and what that means is that use of sysroot is just completely
wrong for NATIVE=y. I was under the impression that sysroot was
necessary for making a relocatable toolchain but I've since come to
believe that was a misconception. Is that so?

I think it would work to pass --with-native-system-header-dir=/include
for cross and "self-targeting cross" compilers and that this would
allow dropping the usr symlink for these cases, and to make NATIVE=y
stop using sysroot at all (and not use this option). (NATIVE=y should
be more than just $HOST=$TARGET.)

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-13 18:55                 ` Rich Felker
@ 2020-05-13 19:34                   ` Michael Forney
  2020-05-13 20:04                     ` Laurent Bercot
  0 siblings, 1 reply; 15+ messages in thread
From: Michael Forney @ 2020-05-13 19:34 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

On 2020-05-13, Rich Felker <dalias@libc.org> wrote:
> On Wed, May 13, 2020 at 11:48:57AM -0700, Michael Forney wrote:
>> It is not relative to /, it is relative to the sysroot, which is
>> determined dynamically based on the location of the compiler binary.
>
> Yes, and what that means is that use of sysroot is just completely
> wrong for NATIVE=y. I was under the impression that sysroot was
> necessary for making a relocatable toolchain but I've since come to
> believe that was a misconception. Is that so?

I believe that a sysroot is necessary for making a relocatable
toolchain, but it doesn't matter if it is /, /$TARGET, or something
else. If you build with --with-sysroot, gcc will look for headers
relative to itself, and will not look in /.

What doesn't seem to be possible is a "half-relocatable" toolchain,
where it searches both in /include relative to the relocated sysroot,
and /usr/include on the target system. Perhaps there is some trick or
patch that could make this work.

> I think it would work to pass --with-native-system-header-dir=/include
> for cross and "self-targeting cross" compilers and that this would
> allow dropping the usr symlink for these cases, and to make NATIVE=y
> stop using sysroot at all (and not use this option). (NATIVE=y should
> be more than just $HOST=$TARGET.)

But until this NATIVE=y refactoring, shouldn't we fix native
toolchains to at least be able to find musl headers? It seems your
intention is to search for headers in both /usr/include and
$SYSROOT/include, but currently, neither of those is searched, only
$SYSROOT/usr/include which does not exist.

My patch is intended to just fix this incorrect path, not to change
the meaning of NATIVE=y. Such a change should probably involve
coordination of Zach van Rijn and Laurent Bercot, both of whom
distribute pre-built native toolchains (currently containing a usr ->
. symlink). Consumers of those toolchains probably expect a
self-contained, relocatable toolchain, since that's what they are
currently getting.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-13 19:34                   ` Michael Forney
@ 2020-05-13 20:04                     ` Laurent Bercot
  2020-05-13 21:51                       ` Rich Felker
  0 siblings, 1 reply; 15+ messages in thread
From: Laurent Bercot @ 2020-05-13 20:04 UTC (permalink / raw)
  To: musl

>My patch is intended to just fix this incorrect path, not to change
>the meaning of NATIVE=y. Such a change should probably involve
>coordination of Zach van Rijn and Laurent Bercot, both of whom
>distribute pre-built native toolchains (currently containing a usr ->
>. symlink). Consumers of those toolchains probably expect a
>self-contained, relocatable toolchain, since that's what they are
>currently getting.

  Yes. I don't know about Zach, but what I want from the tool is indeed
for it to produce self-contained, relocatable toolchains, whether they
are cross- or native. Non-sysrooted toolchains are not very interesting
to me: they have value when you are building a distribution, but less
so when you are building entirely independently from the existing
distribution, which is often the case with musl on glibc-based distros.
Also, a sysrooted toolchain is perfectly usable as the system
toolchain - it just requires a couple symbolic links.

  I 100% support fixing mcm and avoiding the need to patch the produced
toolchains, but please don't change its semantics. Relocatability and
self-containedness are where it's at.

--
  Laurent


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-13 20:04                     ` Laurent Bercot
@ 2020-05-13 21:51                       ` Rich Felker
  2020-05-14  8:40                         ` Laurent Bercot
  0 siblings, 1 reply; 15+ messages in thread
From: Rich Felker @ 2020-05-13 21:51 UTC (permalink / raw)
  To: musl

On Wed, May 13, 2020 at 08:04:10PM +0000, Laurent Bercot wrote:
> >My patch is intended to just fix this incorrect path, not to change
> >the meaning of NATIVE=y. Such a change should probably involve
> >coordination of Zach van Rijn and Laurent Bercot, both of whom
> >distribute pre-built native toolchains (currently containing a usr ->
> >. symlink). Consumers of those toolchains probably expect a
> >self-contained, relocatable toolchain, since that's what they are
> >currently getting.
> 
>  Yes. I don't know about Zach, but what I want from the tool is indeed
> for it to produce self-contained, relocatable toolchains, whether they
> are cross- or native. Non-sysrooted toolchains are not very interesting
> to me: they have value when you are building a distribution, but less
> so when you are building entirely independently from the existing
> distribution, which is often the case with musl on glibc-based distros.
> Also, a sysrooted toolchain is perfectly usable as the system
> toolchain - it just requires a couple symbolic links.
> 
>  I 100% support fixing mcm and avoiding the need to patch the produced
> toolchains, but please don't change its semantics. Relocatability and
> self-containedness are where it's at.

Would you be happy with TARGET=HOST=... giving this behavior while
NATIVE=y additionally gives a real native compiler (that uses the
existing library ecosystem)? Or should I make a new name for the
latter?

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-13 21:51                       ` Rich Felker
@ 2020-05-14  8:40                         ` Laurent Bercot
  0 siblings, 0 replies; 15+ messages in thread
From: Laurent Bercot @ 2020-05-14  8:40 UTC (permalink / raw)
  To: musl

>>  Relocatability and
>>  self-containedness are where it's at.
>
>Would you be happy with TARGET=HOST=... giving this behavior while
>NATIVE=y additionally gives a real native compiler (that uses the
>existing library ecosystem)? Or should I make a new name for the
>latter?

  I personally wouldn't mind, but I at least have used musl-cross-make
in tooling in places I don't work at anymore, and chances are the new
maintainers are not toolchain experts - so incompatible changes would
make upgrading more difficult for them.

  It's a question of terminology, mostly. I always assumed "native" meant
"target=host"; you seem to be saying that it really means 
"non-sysrooted",
which I would rather call "non-sysrooted" or "system compiler". And I
think most people understand "native" the same way as I do, as the
opposite of "cross". So, for maximum clarity, I think it would be wiser
to use another name when you mean "native and non-sysrooted compiler".

--
  Laurent


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains
  2020-05-10 16:35     ` Rich Felker
  2020-05-10 20:35       ` Michael Forney
@ 2020-08-19 21:00       ` Michael Forney
  1 sibling, 0 replies; 15+ messages in thread
From: Michael Forney @ 2020-08-19 21:00 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

On 2020-05-10, Rich Felker <dalias@libc.org> wrote:
> I'll try to get back to this sometime soon, but at the moment my focus
> is already split several ways between mallocng, initial entropy source
> and csprng issues for musl (was considered a prereq for merging
> mallocng but I think it's turning out to be mostly separate which may
> mean I can punt on this for a while), bringing this all together for
> next musl release, and paid work independent from musl.

Now that musl 1.2.1 is out, can we revisit this?

To make sure we're on the same page, do you agree that if I build a
musl-cross-make toolchain with NATIVE=1, and install it to some
arbitrary directory $TOOLCHAIN, then the following is true?

1. The musl headers are located in $TOOLCHAIN/include.
2. $TOOLCHAIN/bin/gcc should include the directory containing musl
headers somewhere in its header search path.
3. $TOOLCHAIN/usr does not exist, so it is not useful to search for
headers in $TOOLCHAIN/usr/include

The only effect of my patch is to add $TOOLCHAIN/include to the header
search path of $TOOLCHAIN/bin/gcc and remove $TOOLCHAIN/usr/include
from the header search path of $TOOLCHAIN/bin/gcc, correcting points 2
and 3 above.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2020-08-19 21:00 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-07  6:49 [musl-cross-make] [PATCH] litecross: Fix system header dir when building native toolchains Michael Forney
2020-03-23  4:34 ` [musl] [musl-cross-make] [PATCH v2] " Michael Forney
2020-05-09  0:27   ` [musl] " Michael Forney
2020-05-10 16:35     ` Rich Felker
2020-05-10 20:35       ` Michael Forney
2020-05-10 21:52         ` Rich Felker
2020-05-13  8:18           ` Michael Forney
2020-05-13 14:37             ` Rich Felker
2020-05-13 18:48               ` Michael Forney
2020-05-13 18:55                 ` Rich Felker
2020-05-13 19:34                   ` Michael Forney
2020-05-13 20:04                     ` Laurent Bercot
2020-05-13 21:51                       ` Rich Felker
2020-05-14  8:40                         ` Laurent Bercot
2020-08-19 21:00       ` Michael Forney

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).