On 24/10/2019 01:55, Jared Stevens via blfs-support wrote:
I have exactly the same command lines on my build, and there is no
errors. I've made some experiments:
-------------
$ echo '#include <stdint.h>' > foo.h
$ gcc -m16 foo.h
In file included from /usr/include/features.h:474,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdint.h:26,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stdint.h:9,
from foo.h:1:
/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such
file
or directory
7 | # include <gnu/stubs-32.h>
| ^~~~~~~~~~~~~~~~
compilation terminated
-------------
$ gcc -m16 -ffreestanding foo.h
(no error)
-------------
Actually, /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stdint.h
contains:
-----------
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
# undef __STDC_LIMIT_MACROS
# define __STDC_LIMIT_MACROS
# undef __STDC_CONSTANT_MACROS
# define __STDC_CONSTANT_MACROS
# endif
# include_next <stdint.h>
#else
# include "stdint-gcc.h"
#endif
and __STDC_HOSTED__ is defined to 0 by option -ffreestanding...
and /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stdint-gcc.h does
not
include anything...
So there might be some problem with the fact that
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stdint.h is not included
first in your case.
Do you have it? If not, that might be a problem with your gcc
installation. Note that -ffreestanding is rarely used, so that it is
normal that you have seen no error up to now with your new installation
of gcc.
Okay so I tried the exact same experiment that you described:
$ echo '#include <stdint.h>' > foo.h
$ gcc -m16 foo.h
*In file included from /usr/include/features.h:474,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdint.h:26,
from foo.h:1:
/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file
The problem is that your gcc directly includes /usr/include/stdint.h
from foo.h, while mine includes
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stdint.h. If I issue the
following command (similar to the sanity check in chapter 6 of LFS):
echo 'int main(){}' | gcc -v -xc - |& grep include
I get:
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed
/usr/include
which means /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include is searched
first.
I have no idea what any of it means, but besides the additional lines
for '*GCC_WRAP_STDINT_H*' it is a mirror of your file.
Yes sorry, I excluded those lines, which just prevent the file from
being included twice.
Also, you mention that the 'stdint-gcc.h' file in your build includes
nothing. Mine apparently includes quite a bit:
$ cat stdint-gcc.h
[snip: Ken has answered about what I meant with "not including"]
>
Like I said, I have no clue what any of this means. I haven't gotten
this advanced into my tutorials for C++ or C yet haha.
:) Basically, a line like "#include <somefile.h>" means the compiler has
to include that file in the program it is compiling. The problem is that
there may be several "somefile.h" on the system, and that there are more
or less obscure mechanisms for coosing which one is included. Clearly,
your compiler includes stdint.h from /usr/include, while mine includes
stdint.h from /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include.
I'd hate to attempt another recompile of GCC just because I always fear
something significant will go wrong this time around. I normally take an
"if it ain't broke don't fix it" mentality with big builds such as the
compiler.
However, if it is indeed an issue with my GCC compiler and it can be
reasonably confirmed as the likely culprit, I will probably make an
image backup of my existing build before attempting another
recompilation of GCC.
Good idea. But depending on the output of the command above for you, you
might have to rebuild it.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
