* [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).