In https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00045.html I noticed the following:
gcc+glibc uses include order: gcc's, then glibc'sgcc+musl uses include order: musl's, then gcc's
Is it intended? Here is an executable (ish) example:
glibc:
$ nix-shell '<nixpkgs>' --pure -A bison --run 'gcc -v -x c -E - </dev/null' |& unnix
/<<NIX>>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include
/<<NIX>>/gcc-10.3.0/include
/<<NIX>>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed
/<<NIX>>/glibc-2.33-50-dev/include
musl:
$ nix-shell '<nixpkgs>' --pure -A pkgsMusl.bison --run 'gcc -v -x c -E - </dev/null' |& unnix
/<<NIX>>/gcc-10.3.0/include
/<<NIX>>/musl-1.2.2-dev/include
/<<NIX>>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-musl/10.3.0/include
/<<NIX>>/gcc-10.3.0/lib/gcc/x86_64-unknown-linux-musl/10.3.0/include-fixed
In case of gnulib's bug above stdarg.h is present in both gcc's version-specific headers and musl's headers. gnulib expects to find headers in musl's copy and fails when gcc's is used.
Is it a reasonable assumption? Should we make glibc's incude order as musl's? Or the other way around? I think "gcc, then libc" is more natural given that gcc places it's headers for namespace cleanup reasons.
In https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00045.html I noticed the following:
gcc+glibcuses include order: gcc's, then glibc'sgcc+musluses include order: musl's, then gcc'sIs it intended? Here is an executable (ish) example:
glibc:musl:In case of
gnulib's bug abovestdarg.his present in both gcc's version-specific headers and musl's headers.gnulibexpects to find headers inmusl's copy and fails whengcc's is used.Is it a reasonable assumption? Should we make glibc's incude order as musl's? Or the other way around? I think "gcc, then libc" is more natural given that gcc places it's headers for namespace cleanup reasons.