editing the gcc specs file causes [-Werror=missing-include-dirs]

[gottaeat]

modifying the

*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}

line in 062-Final_System-GCC to:

%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} -I /usr/lib/gcc/$ARCH-linux-musl/9.1.0/include -I /usr/lib/gcc/$ARCH-linux-musl/9.1.0/include-fixed

causes [-Werror=missing-include-dirs] complaining about /usr/lib/gcc/x86_64-linux-musl/9.1.0 /include-fixed and /usr/lib/gcc/x86_64-linux-musl/9.1.0/include not existing.

i experienced this when installing p11-kit and gnutls. exporting a fresh specs file and replacing it with the modified one gets rid of the errors.

[dslm4515]

I had this issue in an older version of this repo before I uploaded it to github and the solution then was to add -I/usr/lib/gcc/$ARCH-linux-musl/9.1.0/include -I/usr/lib/gcc/$ARCH-linux-musl/9.1.0/include-fixed

[dslm4515]

Strange. I did not have issues compiling gnutls, but had same error for scdoc:

In file included from /usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed/limits.h:34,
                 from src/main.c:5:
/usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed/syslimits.h:7:2: error: #include_next is a GCC extension [-Werror]
    7 | #include_next <limits.h>
      |  ^~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed/limits.h:34,
                 from src/main.c:5:
/usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed/limits.h:194:2: error: #include_next is a GCC extension [-Werror]
  194 | #include_next <limits.h>  /* recurse down to the real one */
      |  ^~~~~~~~~~~~

I'm not sure at this point if there is a need for /usr/lib/gcc/x86_64-linux-musl/9.1.0/include and /usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed need to be added to the GCC specs file.

Omitting those two path does show will a different output (than what LFS documents) when testing the build system in step 62:

grep -B2 '^ /usr/lib/gcc' dummy.log
# Should output:
# #include <...> search starts here:
# /usr/lib/gcc/$ARCH-linux-musl/9.1.0/include-fixed
# /usr/local/include
# /usr/include
# /usr/lib/gcc/$ARCH-linux-musl/9.1.0/include

Edit: Yes, modifying the GCC specs file did allow scdoc to build w/o errors.

[dslm4515]

From BLFS:

Some system headers need to be fixed to be used with GCC. 
This is done during the installation of GCC, and the “fixed”
 headers are installed in /usr/lib/gcc/<machine triplet>/<GCC version>/include-fixed . 
This is harmless if GCC is built during the LFS stage. But if you 
reinstall GCC in BLFS, some of the BLFS packages may be “fixed”. 
If one of those packages is reinstalled afterwards, the “fixed” headers 
are not updated, which may lead to version mismatches. In case that 
happens, the “fixed” headers must be updated by running (as root): /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/install-tools/mkheaders . 
The machine triplet may be different on a 32bit system.

Not sure if this hint to what the purpose of the include-fixed directory.

Any Idea, @firasuke ?

[firasuke]

While I don't have a copy of MLFS, let alone a working copy of it, I can neither reproduce the issue above nor attempt to fix it (I'm only reading several *LFS projects as a reference to keep my toolchains sane enough).

To answer your question, yes that hint from the BLFS project seems related to the error you're facing. It also provides several solutions to the problem, the first being attempting the final GCC install during the LFS stage which I presume is what you're doing as you're building the final GCC before most of the final packages, and the second being running the /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/install-tools/mkheaders file which should fix the problem.

I'd recommend against adding include directories in the specs file, and I'd also run the relative mkheaders script before building and installing the final GCC (even though BLFS indicates that it's related to the installation process only).

[gottaeat]

@dslm4515

Yes, modifying the GCC specs file did allow scdoc to build w/o errors.

if i leave the specs file as it is and don't modify it as your documentation suggests, it won't spit out the [-Werror=missing-include-dirs] errors but then if i run the sanity check thingy, it won't list include-fixed:

~ $ echo 'int main(){}' > dummy.c
~ $ cc dummy.c -v -Wl,--verbose &> dummy.log
~ $ readelf -l a.out | grep ': /lib'
      [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]
~ $ grep 'crt[1in].o succeeded' dummy.log
attempt to open /usr/lib/gcc/x86_64-linux-musl/9.2.0/../../../../lib/Scrt1.o succeeded
attempt to open /usr/lib/gcc/x86_64-linux-musl/9.2.0/../../../../lib/crti.o succeeded
attempt to open /usr/lib/gcc/x86_64-linux-musl/9.2.0/../../../../lib/crtn.o succeeded
~ $ grep -B2 '^ /usr/lib/gcc' dummy.log
#include <...> search starts here:
 /usr/include
 /usr/lib/gcc/x86_64-linux-musl/9.2.0/include
~ $ grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
SEARCH_DIR("/usr/x86_64-pc-linux-musl/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-musl/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");

@firasuke i've been building my systems for a while and never had this problem with the traditional glibc+gcc combination that the lfs+blfs books offer documentation for, any idea why this is happening with this specific documentation?

[firasuke]

According to the official GNU documentation:

Installing GCC automatically creates and installs the fixed header files, by running a program called fixincludes. Normally, you don’t need to pay attention to this. But there are cases where it doesn’t do the right thing automatically.

If you update the system’s header files, such as by installing a new system version, the fixed header files of GCC are not automatically updated. They can be updated using the mkheaders script installed in libexecdir/gcc/target/version/install-tools/.

Either fixincludes isn't being called (I've read many GCC recipes that use sed to remove fixincludes):

# Do not run fixincludes
  sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in

Or fixincludes is being called (I've skimmed through your documentation and you don't seem to prevent fixincludes from running) and it's not doing the right thing automatically (which is probably what you're facing), hence the mkheaders script can be called to update the system's headers file, or the fixincludes call can be removed (previous versions of several *LFS projects used to do this if I recall correctly).

[dslm4515]

@firasuke I agree, the GCC specs file should have little or no modification. Thanks for the explanation!

@mssx86 Thanks for confirming modifying the gcc specs file fixed your issue.

I am in the middle of running another build of MLFS, with a few changes:

• Reduce binutils to a single build for /tools
• Reduce gcc to a single build for /tools
• Add CFLAGS & CXXFLAGS to disable optimizations for cross-tools (as recommended by @firasuke)
• Do not add fixed header paths in the GCC specs file when adjusting tool chain

And this build will be used to make another build of BMLFS. I'll see if this issue comes up for any other package.

P.S. I got a host using a Intel(R) Celeron(R) CPU G3900TE @ 2.30GHz with 8GB of DDR4 ...WOW: GCC of cross tools in 7 mins! I've been using Core 2 Duo CPUs for my builds

Edit: Fixed typos

[firasuke]

Again, you're most welcome!

Also, kindly look into disabling the call to fixincludes or running mkheaders if you decided to keep the call to fixincludes, and see if it'll solve the issue above.

[gottaeat]

@dslm4515 no, modifying the specs file gives me the error, leaving it untouched fixes it but the sanity check does not show that the include-fixed directory being registered.

@firasuke

or running mkheaders if you decided to keep the call to fixincludes, and see if it'll solve the issue above.

i built a fresh gcc-9.2.1-20191005 using these flags, didn't run the sed command to disabling the call of fixincludes and ran mkheaders manually but didn't seem like it worked, the /usr/lib/gcc/x86_64-linux-musl/9.2.1/include-fixed doesn't appear as you can see here:

 install-tools # ls
fixinc.sh  fixincl  mkheaders  mkinstalldirs
 install-tools # id -u
0
 install-tools # ./mkheaders
 install-tools #
~ $ id -u
1000
~ $ echo 'int main(){}' > dummy.c
~ $ cc dummy.c -v -Wl,--verbose &> dummy.log
~ $ grep -B2 '^ /usr/lib/gcc' dummy.log
#include <...> search starts here:
 /usr/include
 /usr/lib/gcc/x86_64-linux-musl/9.2.1/include
~ $

i will now try running the sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in before make to see if that changes anything.

[gottaeat]

@firasuke alright, i ran sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in before make using the same flags i linked above but still don't see include-fixed directory being registered when i run the sanity check.

~ # ls -la /usr/lib/gcc/x86_64-linux-musl/9.2.1/ | grep include
drwxrwxr-x 3 root root    4096 Oct  8 15:15 include
drwxrwxr-x 2 root root    4096 Oct  8 15:28 include-fixed

~ # echo 'int main(){}' > dummy.c
~ # cc dummy.c -v -Wl,--verbose &> dummy.log
~ # grep -B2 '^ /usr/lib/gcc' dummy.log
#include <...> search starts here:
 /usr/include
 /usr/lib/gcc/x86_64-linux-musl/9.2.1/include

~ # id -u
0
~ # /usr/libexec/gcc/x86_64-linux-musl/9.2.1/install-tools/mkheaders

~ # echo 'int main(){}' > dummy.c
~ # cc dummy.c -v -Wl,--verbose &> dummy.log
~ # grep -B2 '^ /usr/lib/gcc' dummy.log
#include <...> search starts here:
 /usr/include
 /usr/lib/gcc/x86_64-linux-musl/9.2.1/include

~ # 

the reason for timestamps for include and include-fixed being different is because i had to change to ownership back to root since it gets installed as the user who built it (as blfs book suggests).

[firasuke]

the reason for timestamps for include and include-fixed being different is because i had to change to ownership back to root since it gets installed as the user who built it (as blfs book suggests).

Why are you following the BLFS book (and I presume you're reading this Chapter 13 - GCC-9.2.0)? Shouldn't this GCC build be part of the LFS book as mentioned in Chapter 6 - GCC-9.2.0?

As listed in Chapter 6 - GCC-9.2.0, shouldn't you only be changing ownership (first to nobody then back to root) if your intention was to run the test suite?

[gottaeat]

@firasuke

if your intention was to run the test suite?

i have never mentioned running the test suite in this thread.

Why are you following the BLFS book

i am not following blfs. i just updated my gcc to 9.2.1-20191005 from 9.2.0 stable and wanted to try those two solutions you mentioned which didn't work for my case. if you build gcc as a normal user then run make install as uid 0, the include and include-fixed dirs will be owned by the user who built them, not by root. that's what i meant.

Shouldn't this GCC build be part of the LFS book

i can't see how relevant what you said is to what i'm saying but i'm getting the said [-Werror=missing-include-dirs] in the system i'm currently using daily, which was built by following my fork of this book. the gcc build steps are identical except for the used gcc version and the applied patches. i had the exact same problem when i built a system by strictly following this book as well.

[firasuke]

i have never mentioned running the test suite in this thread.

I didn't say that your intention was to run the test suite. What I meant by that is that you shouldn't be changing the ownership of the files unless you're planning on running the test suite, that is according to Chapter 6 - GCC-9.2.0.

Unfortunately, I don't have the time to be testing MLFS, and I've only just quickly skimmed through its documentation so I can't replicate or attempt to fix any of the problems mentioned above especially with these kind of errors that require a lot of trials to get them right (documentation is heavily lacking).

i am not following blfs.

Well you were borrowing suggestions from the GCC build mentioned in BLFS, when clearly the GCC you're attempting to build is Chapter 6 - GCC-9.2.0. It's even mentioned in the BLFS hint above that you shouldn't face this error if you built GCC in the LFS stage:

This is harmless if GCC is built during the LFS stage. But if you reinstall GCC in BLFS, some of the BLFS packages may be “fixed”.

So I assumed that you mistook the GCC build in BLFS for the early build in LFS, and I suggested that you try to closely follow the instructions mentioned in the early stage build in Chapter 6 - GCC-9.2.0 before reading the build in BLFS.

[gottaeat]

@firasuke

What I meant by that is that you shouldn't be changing the ownership of the files unless you're planning on running the test suite

i don't think you're following me here. if you build gcc as a user other than root, then install as root, even though you installed it as a root, the /usr/lib/gcc/x86_64-linux-musl/9.2.1/include-fixed/ and /usr/lib/gcc/x86_64-linux-musl/9.2.1/include directories will be owned by the user who built gcc before it got installed by root, not by root. this will happen no matter which book or which step you're following. i'm changing the ownership to root for basic security measures, not because the book told me to, and because it's in blfs doesn't mean that it doesn't apply to the way things are built generally.

Well you were borrowing suggestions from the GCC build mentioned in BLFS

i literally took one (1) recommendation which is just running chown -R root:root /usr/lib/gcc/x86_64-linux-musl/9.2.1/include{,-fixed} for the sake of security.

when clearly the GCC you're attempting to build is Chapter 6 - GCC-9.2.0.

i have explicitly told that i am facing this error in a complete system, not while building the base.

So I assumed that you mistook the GCC build in BLFS for the early build in LFS

no, i'm fairly familiar with lfs and blfs as i've built countless systems using both. you don't really have to make assumptions when what i'm telling you is open and clear. i'm even explaining why i did what.

you still haven't replied to my initial question though.

[firasuke]

Are the directories include and include-fixed being created at all? If so, are they being populated (with and without the call to fixincludes and mkheaders)? Are there any environment variables that may be influencing the include path, like CPATH, C_INCLUDE_PATH and CPLUS_INCLUDE_PATH?

[gottaeat]

Are the directories include and include-fixed being created at all?

yes, they're created and populated as you can see in my original reply here. they get created in all cases no matter if i run the sed to remove the call to fixincludes or before i run mkheaders manually.

Are there any environment variables that may be influencing the include path, like CPATH, C_INCLUDE_PATH and CPLUS_INCLUDE_PATH?

i have no variables set that changes the way compiler works except for xdg/pkgconfig dirs:

 ~ % printenv
ARCH=x86_64
OPENGL_PROFILE=xorg-x11
INPUTRC=/etc/inputrc
MAIL=/var/mail/mss
USER=mss
SHLVL=3
HOME=/home/mss
LESS=-R -M --shift 5
HUSHLOGIN=FALSE
PAGER=/usr/bin/less
MAKEFLAGS=-j 3
INFOPATH=/usr/share/info
LOGNAME=mss
PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig
TERM=rxvt-unicode-256color
WINDOWPATH=1
PATH=/usr/sbin:/usr/bin:/sbin:/bin:/mss/bin
XORG_PREFIX=/usr
DISPLAY=:0
LANG=en_US.utf8
XDG_CONFIG_HOME=/home/mss/.config
XAUTHORITY=/home/mss/.Xauthority
HZ=100
SHELL=/bin/yash
_buildformusl=--build=x86_64-linux-musl --host=x86_64-linux-musl
PWD=/home/mss
GPG_TTY=/dev/pts/2
XDG_DATA_DIRS=/usr/share
XDG_CONFIG_DIRS=/etc/xdg
GSETTINGS_BACKEND=dconf
MANPATH=/usr/share/man
EDITOR=/usr/bin/vim
TERMINFO=/usr/share/terminfo
COLORTERM=rxvt-xpm

[firasuke]

Hmm, that's weird... So if I understood correctly, you're receiving these missing include directory errors when attempting to build certain packages, even though these directories exist and are populated, and you can get rid of these errors by not modifying the specs file (or by creating a fresh specs file), but you're concerned about the sanity of the toolchain (when comparing your output to what's mentioned in LFS) as it doesn't show include-fixed in the GCC headers include path?

So basically include-fixed isn't being added to the GCC include path regardless of what you do, and you're questioning the reason behind that and the need for include-fixed in general.

[gottaeat]

@firasuke that is exactly it, yes.

if i don't add anything to the specs file, everything builds fine but include-fixed doesn't get listed in the include path, only /usr/include and /usr/lib/gcc/x86_64-linux-musl/9.2.1/include shows up when the sanity check steps are ran.

only way to make it show up in the include path is to modify the specs file but that causes [-Werror=missing-include-dirs] with p11-kit and gnutls when building them. they still build fine without the build failing though.

[firasuke]

Hmm, I know this may sound a bit ridiculous but are you sure you're grepping the entire include directories from dummy.log? Could you possibly change that -B2 to a full search instead, perhaps attempt cpp -x c -v and cpp -x c++ -v (with your own version of cpp)?

[firasuke]

Well what if the entire include-fixed directory isn't needed? The README file located inside the include-fixed directory states that sometimes headers that do not need a fix get fixed, and maybe that's the case here; hence, GCC is refusing to add them as they're "limited" or "not needed"?

[gottaeat]

Hmm, I know this may sound a bit ridiculous but are you sure you're grepping the entire include directories from dummy.log?

i thought about that, then piped it to less instead of redirecting to dummy.log, here's the entire part where it searches for include directories:

gcc version 9.2.1 20191005 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-linux-musl/9.2.1/cc1 -quiet -v dummy.c -quiet -dumpbase dummy.c -mtune=generic -march=x86-64 -auxbase dummy -version -o /tmp/ccgjIBDO.s
GNU C17 (GCC) version 9.2.1 20191005 (x86_64-linux-musl)
        compiled by GNU C version 9.2.1 20191005, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-musl/9.2.1/../../../../x86_64-linux-musl/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /usr/lib/gcc/x86_64-linux-musl/9.2.1/include
End of search list.

Well what if the entire include-fixed directory isn't needed?

possible, i'm not a c or c++ programmer, i only know the very basics of c so your guess is better than mine.

The README file located inside the include-fixed directory

i don't have README file inside include-fixed:

~ $ ls -la /usr/lib/gcc/x86_64-linux-musl/9.2.1/include-fixed
total 20
drwxrwxr-x 2 root root 4096 Oct  8 15:32 .
drwxrwxr-x 6 root root 4096 Oct  8 17:24 ..
-rw-r--r-- 1 root root 6089 Oct  8 15:32 limits.h
-rw-r--r-- 1 root root  330 Oct  8 15:32 syslimits.h
~ $

[dslm4515]

My last build had a modified gcc specs file. I only added one path (instead of two, like in my documentation a few commits before):

*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} -I /usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed

I was able to build p11-kit-0.23.16.1 and gnutls-3.6.9 without build errors, strangely.

Here's the result of the sanity check on this build:

biruda [~] $ echo 'int main(){}' > dummy.c
biruda [~] $ cc dummy.c -v -Wl,--verbose &> dummy.log
biruda [~] $ readelf -l a.out | grep ': /lib'
      [Requesting program interpreter: /lib/ld-musl-x86_64.so.1
biruda [~] $ grep 'crt[1in].o succeeded' dummy.log
attempt to open /usr/lib/gcc/x86_64-linux-musl/9.1.0/../../../../lib/Scrt1.o succeeded
attempt to open /usr/lib/gcc/x86_64-linux-musl/9.1.0/../../../../lib/crti.o succeeded
attempt to open /usr/lib/gcc/x86_64-linux-musl/9.1.0/../../../../lib/crtn.o succeeded
biruda [~] $ grep -B2 '^ /usr/lib/gcc' dummy.log
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed
 /usr/local/include
 /usr/include
 /usr/lib/gcc/x86_64-linux-musl/9.1.0/include
biruda [~] $ grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
SEARCH_DIR("/usr/x86_64-linux-musl/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-linux-musl/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");

The contents of those two directories:

biruda [~] $ ls /usr/lib/gcc/x86_64-linux-musl/9.1.0/include
adxintrin.h           avx512pfintrin.h           bmi2intrin.h        float.h        mmintrin.h       rdseedintrin.h  stdint.h            vtv_utils.h
ammintrin.h           avx512vbmi2intrin.h        bmiintrin.h         fma4intrin.h   movdirintrin.h   rtmintrin.h     stdnoreturn.h       waitpkgintrin.h
avx2intrin.h          avx512vbmi2vlintrin.h      bmmintrin.h         fmaintrin.h    mwaitxintrin.h   sgxintrin.h     tbmintrin.h         wbnoinvdintrin.h
avx5124fmapsintrin.h  avx512vbmiintrin.h         cet.h               fxsrintrin.h   nmmintrin.h      shaintrin.h     tmmintrin.h         wmmintrin.h
avx5124vnniwintrin.h  avx512vbmivlintrin.h       cetintrin.h         gcov.h         omp.h            smmintrin.h     unwind.h            x86intrin.h
avx512bitalgintrin.h  avx512vlbwintrin.h         cldemoteintrin.h    gfniintrin.h   openacc.h        ssp             vaesintrin.h        xmmintrin.h
avx512bwintrin.h      avx512vldqintrin.h         clflushoptintrin.h  ia32intrin.h   pconfigintrin.h  stdalign.h      varargs.h           xopintrin.h
avx512cdintrin.h      avx512vlintrin.h           clwbintrin.h        immintrin.h    pkuintrin.h      stdarg.h        vpclmulqdqintrin.h  xsavecintrin.h
avx512dqintrin.h      avx512vnniintrin.h         clzerointrin.h      iso646.h       pmmintrin.h      stdatomic.h     vtv_fail.h          xsaveintrin.h
avx512erintrin.h      avx512vnnivlintrin.h       cpuid.h             lwpintrin.h    popcntintrin.h   stdbool.h       vtv_malloc.h        xsaveoptintrin.h
avx512fintrin.h       avx512vpopcntdqintrin.h    cross-stdarg.h      lzcntintrin.h  prfchwintrin.h   stddef.h        vtv_map.h           xsavesintrin.h
avx512ifmaintrin.h    avx512vpopcntdqvlintrin.h  emmintrin.h         mm3dnow.h      quadmath.h       stdfix.h        vtv_rts.h           xtestintrin.h
avx512ifmavlintrin.h  avxintrin.h                f16cintrin.h        mm_malloc.h    quadmath_weak.h  stdint-gcc.h    vtv_set.h
biruda [~] $ ls /usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed/
README  limits.h  syslimits.h

[firasuke]

I just checked with my custom gcc-musl toolchain that I recently redesigned (a single stage cross-compilation build, and a single stage native build, with latest upstream sources, and it closely resembles that of LFS now), and it seems that include-fixed isn't being used at all:

[glaucus@Satellite play]$ x86_64-pc-linux-musl-cpp -x c -v

Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-musl-cpp
Target: x86_64-pc-linux-musl
Configured with: /home/glaucus/temporary/toolchain/sources/gcc/configure --target=x86_64-pc-linux-musl --prefix=/toolchain --with-local-prefix=/toolchain --with-native-system-header-dir=/toolchain/include --disable-shared --disable-multilib --enable-threads=single --with-arch=x86-64 --disable-bootstrap --enable-languages=c,c++ --disable-libssp --disable-libquadmath --disable-libgomp --disable-libvtv --disable-werror --disable-nls --disable-decimal-float --with-gmp=/toolchain --with-mpfr=/toolchain --with-mpc=/toolchain --without-isl --without-zstd --with-linker-hash-style=gnu --with-sysroot=/home/glaucus --without-headers --with-newlib --disable-libatomic --disable-libstdcxx
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191001 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
 /home/glaucus/toolchain/bin/../libexec/gcc/x86_64-pc-linux-musl/10.0.0/cc1 -E -quiet -v -iprefix /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/ - -mtune=generic -march=x86-64
ignoring duplicate directory "/home/glaucus/toolchain/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../x86_64-pc-linux-musl/include"
ignoring duplicate directory "/toolchain/include"
ignoring duplicate directory "/home/glaucus/toolchain/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-musl/10.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../x86_64-pc-linux-musl/include
 /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/include
 /toolchain/include
End of search list.

And for c++:

[glaucus@Satellite play]$ x86_64-pc-linux-musl-cpp -x c++ -v

Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-musl-cpp
Target: x86_64-pc-linux-musl
Configured with: /home/glaucus/temporary/toolchain/sources/gcc/configure --target=x86_64-pc-linux-musl --prefix=/toolchain --with-local-prefix=/toolchain --with-native-system-header-dir=/toolchain/include --disable-shared --disable-multilib --enable-threads=single --with-arch=x86-64 --disable-bootstrap --enable-languages=c,c++ --disable-libssp --disable-libquadmath --disable-libgomp --disable-libvtv --disable-werror --disable-nls --disable-decimal-float --with-gmp=/toolchain --with-mpfr=/toolchain --with-mpc=/toolchain --without-isl --without-zstd --with-linker-hash-style=gnu --with-sysroot=/home/glaucus --without-headers --with-newlib --disable-libatomic --disable-libstdcxx
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191001 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
 /home/glaucus/toolchain/bin/../libexec/gcc/x86_64-pc-linux-musl/10.0.0/cc1plus -E -quiet -v -iprefix /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/ -D_GNU_SOURCE - -mtune=generic -march=x86-64
ignoring duplicate directory "/home/glaucus/toolchain/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../include/c++/10.0.0"
ignoring duplicate directory "/home/glaucus/toolchain/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../include/c++/10.0.0/x86_64-pc-linux-musl"
ignoring duplicate directory "/home/glaucus/toolchain/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../include/c++/10.0.0/backward"
ignoring duplicate directory "/home/glaucus/toolchain/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../x86_64-pc-linux-musl/include"
ignoring duplicate directory "/toolchain/include"
ignoring duplicate directory "/home/glaucus/toolchain/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-musl/10.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../include/c++/10.0.0
 /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../include/c++/10.0.0/x86_64-pc-linux-musl
 /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../include/c++/10.0.0/backward
 /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/../../../../x86_64-pc-linux-musl/include
 /home/glaucus/toolchain/bin/../lib/gcc/x86_64-pc-linux-musl/10.0.0/include
 /toolchain/include
End of search list.

And it doesn't show include-fixed as well, so I'm guessing that it's mostly not needed.

[firasuke]

I only added one path (instead of two, like in my documentation a few commits before):

Well it's good to know that removing the already included directory resolved the error, but the question of whether include-fixed is really needed still remains... I've checked several custom built systems including those that use Linux, those on ARM, and some of the BSDs, and they all seem to remove include-fixed as it's either included for legacy purposes, or isn't mostly needed as it wrongly corrects headers that don't need correction.

[dslm4515]

My current build has /cross-tools and /tools built with gcc-9.2.0 with single builds of binutils and GCC. I will build the final system without adding .../include and ../include-fixed and then build BMLFS to see what breaks.... Updating BMLFS to have LLVM 9.0.0 and a possible working utmpd service.

On a stranger note, My armv7l-musleabihf can build openssh-8.0.0p1 but the binaries all exit with killed. I still gotta study @firasuke 's S6-rc buildscripts though... since I want my s6+s6-rc init system using latest versions.

[dslm4515]

Yeah, @firasuke , seems that include-fixed causes more random issues when added to the GCC specs file.

I'll opt to not add those two include paths to the system GCC specs file.

[firasuke]

My current build has /cross-tools and /tools built with gcc-9.2.0 with single builds of binutils and GCC. I will build the final system without adding .../include and ../include-fixed and then build BMLFS to see what breaks.... Updating BMLFS to have LLVM 9.0.0 and a possible working utmpd service.

That would be cool, please report your findings! You also seem to have a README in your include-fixed, can you kindly check its contents as well?

On a stranger note, My armv7l-musleabihf can build openssh-8.0.0p1 but the binaries all exit with killed. I still gotta study @firasuke 's S6-rc buildscripts though... since I want my s6+s6-rc init system using latest versions.

Yup, glaucus uses the latest s6 + s6-rc, also s6 received another big update. Please check their mailing lists, and ask skarnet in the s6 irc channel if you needed help.

[dslm4515]

''' Biruda [ ~ ] $ cat /usr/lib/gcc/x86_64-linux-musl/9.1.0/include-fixed/README This README file is copied into the directory for GCC-only header files when fixincludes is run by the makefile for GCC.

Many of the files in this directory were automatically edited from the standard system header files by the fixincludes process. They are system-specific, and will not work on any other kind of system. They are also not part of GCC. The reason we have to do this is because GCC requires ANSI C headers and many vendors supply ANSI-incompatible headers.

Because this is an automated process, sometimes headers get "fixed" that do not, strictly speaking, need a fix. As long as nothing is broken by the process, it is just an unfortunate collateral inconvenience. We would like to rectify it, if it is not "too inconvenient". '''

I've tried to ask skarnet in the s6 IRC channel but got nothing. I've never used an IRC channel before so I'm probably doing something wrong.

[firasuke]

Because this is an automated process, sometimes headers get "fixed" that do not, strictly speaking, need a fix. As long as nothing is broken by the process, it is just an unfortunate collateral inconvenience. We would like to rectify it, if it is not "too inconvenient".

This might be the case.

I've tried to ask skarnet in the s6 IRC channel but got nothing. I've never used an IRC channel before so I'm probably doing something wrong.

That's weird, the s6 irc channel has some nice people that are willing to offer help almost always.

[gottaeat]

@firasuke @dslm4515 well, when i left the specs file unmodified and when i modified it to add paths to both include + include-fixed or just include-fixed to the specs file, things got compiled without a make error so i guess it's safe to say that what the README says is true and it's safe to close the issue.

also for @firasuke, can you point me to the patches you built the gcc-10 you had in your post with?

[dslm4515]

Yes I think I removed all instances of modifying the GCC specs file for those fixed headers...in the docs.

[firasuke]

also for @firasuke, can you point me to the patches you built the gcc-10 you had in your post with?

I don't apply any patches to my toolchains. The only source modifications that I've used, are the ones mentioned in LFS plus a few of my own that help the toolchain further isolate from the host, and point correctly to the correct linkers for both cross-compilation and native compilation.

Here's the ceras file (recipe) that I'm using for the single stage cross GCC build: https://github.com/firasuke/glaucus/blob/master/cerata/gcc/ceras/cross.ceras

and the one for the single stage native GCC build: https://github.com/firasuke/glaucus/blob/master/cerata/gcc/ceras/native.ceras

Please keep in mind that I'm constantly modifying these and constantly testing different toolchain designs. The previous design was similar to that of MLFS, but didn't build correctly at the native stage 2 GCC.

This new design just recently started working. It uses a single build for the cross compilation GCC, and a single build for the native compilation GCC. It's still under heavy testing, but it looks promising. I'll be further stripping it down once I build everything successfully with it.

Hope that helps.