-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
editing the gcc specs file causes [-Werror=missing-include-dirs] #13
Comments
I had this issue in an older version of this repo before I uploaded it to github and the solution then was to add |
Strange. I did not have issues compiling gnutls, but had same error for scdoc:
I'm not sure at this point if there is a need for Omitting those two path does show will a different output (than what LFS documents) when testing the build system in step 62:
Edit: |
From BLFS:
Not sure if this hint to what the purpose of the Any Idea, @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 I'd recommend against adding include directories in the specs file, and I'd also run the relative |
if i leave the specs file as it is and don't modify it as your documentation suggests, it won't spit out the
@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? |
According to the official GNU documentation:
Either # Do not run fixincludes
sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in Or |
@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:
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 Edit: Fixed typos |
Again, you're most welcome! Also, kindly look into disabling the call to |
@dslm4515 no, modifying the specs file gives me the error, leaving it untouched fixes it but the sanity check does not show that the
i built a fresh gcc-9.2.1-20191005 using these flags, didn't run the sed command to disabling the call of
i will now try running the |
@firasuke alright, i ran
the reason for timestamps for |
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 |
i have never mentioned running the test suite in this thread.
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
i can't see how relevant what you said is to what i'm saying but i'm getting the said |
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).
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:
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. |
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
i literally took one (1) recommendation which is just running
i have explicitly told that i am facing this error in a complete system, not while building the base.
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. |
Are the directories |
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
i have no variables set that changes the way compiler works except for xdg/pkgconfig dirs:
|
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 So basically |
@firasuke that is exactly it, yes. if i don't add anything to the specs file, everything builds fine but only way to make it show up in the include path is to modify the specs file but that causes |
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 |
Well what if the entire |
i thought about that, then piped it to
possible, i'm not a c or c++ programmer, i only know the very basics of c so your guess is better than mine.
i don't have README file inside
|
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):
I was able to build Here's the result of the sanity check on this build:
The contents of those two directories:
|
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 [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 [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 |
Well it's good to know that removing the already included directory resolved the error, but the question of whether |
My current build has On a stranger note, My |
Yeah, @firasuke , seems that I'll opt to not add those two include paths to the system GCC specs file. |
That would be cool, please report your findings! You also seem to have a
Yup, glaucus uses the latest |
''' Many of the files in this directory were automatically edited from the Because this is an automated process, sometimes headers get "fixed" 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. |
This might be the case.
That's weird, the |
@firasuke @dslm4515 well, when i left the specs file unmodified and when i modified it to add paths to both also for @firasuke, can you point me to the patches you built the gcc-10 you had in your post with? |
Yes I think I removed all instances of modifying the GCC specs file for those fixed headers...in the docs. |
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: and the one for the single stage native GCC build: 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. |
modifying the
line in
062-Final_System-GCC
to: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
andgnutls
. exporting a freshspecs
file and replacing it with the modified one gets rid of the errors.The text was updated successfully, but these errors were encountered: