[blfs-support] Compilation failures - missing header files

[Alex via blfs-support]

Hi,

I have been trying in vain to get a BLFS (stable v8.3) system up and
running for the last 3 weeks, I have tried 5 times so far and it always
ends up with an error message about missing header files.

LFS (stable v8.3) compiles without any problems at all, but when I start
off with BLFS, packages fail to compile with error messages that
complain about C style header files. I tried hard coding the path to the
C style header file and the compilation continues only to end up with
another missing header file. This behaviour is quite random, a package
that successfully compiled on my first try failed to compile on the
second try and so on.

This is a snippet from the most recent try, from package smartmontools:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

make[1]: Entering directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
make  all-am
make[2]: Entering directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
g++ -DHAVE_CONFIG_H -I.  -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT smartctl.o -MD -MP -MF .deps/smartctl.Tpo
-c -o smartctl.o smartctl.cpp
g++ -DHAVE_CONFIG_H -I.  -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT atacmdnames.o -MD -MP -MF .deps/atacmdname
s.Tpo -c -o atacmdnames.o atacmdnames.cpp
g++ -DHAVE_CONFIG_H -I.  -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT atacmds.o -MD -MP -MF .deps/atacmds.Tpo -c
 -o atacmds.o atacmds.cpp
g++ -DHAVE_CONFIG_H -I.  -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT ataidentify.o -MD -MP -MF .deps/ataidentif
y.Tpo -c -o ataidentify.o ataidentify.cpp
g++ -DHAVE_CONFIG_H -I.  -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT ataprint.o -MD -MP -MF .deps/ataprint.Tpo
-c -o ataprint.o ataprint.cpp
mv -f .deps/atacmdnames.Tpo .deps/atacmdnames.Po
g++ -DHAVE_CONFIG_H -I.  -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT dev_ata_cmd_set.o -MD -MP -MF
.deps/dev_ata_cmd_set.Tpo -c -o dev_ata_cmd_set.o dev_ata_cmd_set.cpp
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
                 from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                 from /usr/include/c++/8.2.0/string:52,
                 from utility.h:36,
                 from dev_interface.h:23,
                 from atacmds.h:30,
                 from dev_ata_cmd_set.cpp:20:
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
                 from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                 from /usr/include/c++/8.2.0/string:52,
                 from utility.h:36,
                 from ataidentify.cpp:25:
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
                 from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                 from /usr/include/c++/8.2.0/string:52,
                 from utility.h:36,
                 from dev_interface.h:23,
                 from atacmds.h:30,
                 from atacmds.cpp:34:
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
                 from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                 from /usr/include/c++/8.2.0/string:52,
                 from utility.h:36,
                 from dev_interface.h:23,
                 from atacmds.h:30,
                 from ataprint.cpp:35:
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
compilation terminated.
compilation terminated.
compilation terminated.
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
                 from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                 from /usr/include/c++/8.2.0/string:52,
                 from /usr/include/c++/8.2.0/stdexcept:39,
                 from smartctl.cpp:31:
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:1231: ataidentify.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:1231: ataprint.o] Error 1
make[2]: *** [Makefile:1231: smartctl.o] Error 1
make[2]: *** [Makefile:1231: dev_ata_cmd_set.o] Error 1
make[2]: *** [Makefile:1231: atacmds.o] Error 1
make[2]: Leaving directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
make[1]: *** [Makefile:879: all] Error 2
make[1]: Leaving directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Has anyone encountered this or something similar ? The header file
stdlib.h does exist but, the iostream.h doesn't exist as required by
other packages that failed in previous runs, which is where I get lost
as, I cannot hard code the path and get compilation to proceed. I do not
think it is a good idea to hard code the path to the header files, there
must be something wrong with the system configuration. It has been long
time since I compiled LFS/BLFS or did some C/C++ programming, I need
some directions as to what  I should be looking at to troubleshoot this
problem.

Thanks,

Al

[Oleh Malyi via blfs-support]

Hello Alex,
your BLFS doesn't have the file stdlib.h from gcc-8.2.0.
You can try rebuild this compiler according its instruction on page
http://www.linuxfromscratch.org/blfs/view/8.3/general/gcc.html

ср, 3 жПвт. 2018 П 19:43 Alex via blfs-support <

Post by Alex via blfs-support
Hi,
I have been trying in vain to get a BLFS (stable v8.3) system up and
running for the last 3 weeks, I have tried 5 times so far and it always
ends up with an error message about missing header files.
LFS (stable v8.3) compiles without any problems at all, but when I start
off with BLFS, packages fail to compile with error messages that
complain about C style header files. I tried hard coding the path to the
C style header file and the compilation continues only to end up with
another missing header file. This behaviour is quite random, a package
that successfully compiled on my first try failed to compile on the
second try and so on.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
make[1]: Entering directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
make all-am
make[2]: Entering directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT smartctl.o -MD -MP -MF .deps/smartctl.Tpo
-c -o smartctl.o smartctl.cpp
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT atacmdnames.o -MD -MP -MF .deps/atacmdname
s.Tpo -c -o atacmdnames.o atacmdnames.cpp
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT atacmds.o -MD -MP -MF .deps/atacmds.Tpo -c
-o atacmds.o atacmds.cpp
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT ataidentify.o -MD -MP -MF .deps/ataidentif
y.Tpo -c -o ataidentify.o ataidentify.cpp
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT ataprint.o -MD -MP -MF .deps/ataprint.Tpo
-c -o ataprint.o ataprint.cpp
mv -f .deps/atacmdnames.Tpo .deps/atacmdnames.Po
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT dev_ata_cmd_set.o -MD -MP -MF
.deps/dev_ata_cmd_set.Tpo -c -o dev_ata_cmd_set.o dev_ata_cmd_set.cpp
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from utility.h:36,
from dev_interface.h:23,
from atacmds.h:30,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from utility.h:36,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from utility.h:36,
from dev_interface.h:23,
from atacmds.h:30,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from utility.h:36,
from dev_interface.h:23,
from atacmds.h:30,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
compilation terminated.
compilation terminated.
compilation terminated.
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from /usr/include/c++/8.2.0/stdexcept:39,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:1231: ataidentify.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:1231: ataprint.o] Error 1
make[2]: *** [Makefile:1231: smartctl.o] Error 1
make[2]: *** [Makefile:1231: dev_ata_cmd_set.o] Error 1
make[2]: *** [Makefile:1231: atacmds.o] Error 1
make[2]: Leaving directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
make[1]: *** [Makefile:879: all] Error 2
make[1]: Leaving directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Has anyone encountered this or something similar ? The header file
stdlib.h does exist but, the iostream.h doesn't exist as required by
other packages that failed in previous runs, which is where I get lost
as, I cannot hard code the path and get compilation to proceed. I do not
think it is a good idea to hard code the path to the header files, there
must be something wrong with the system configuration. It has been long
time since I compiled LFS/BLFS or did some C/C++ programming, I need
some directions as to what I should be looking at to troubleshoot this
problem.
Thanks,
Al
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[Alex Bosworth via blfs-support]

Hi Oleh,

Thanks, during my second try, I did attempt to recompile gcc and glibc,
encountered the same problem of missing headers - stdlib.h and iostream.h.

I'm out of ideas, about to give up and go back to funtoo.

Alex

On Wed, 3 Oct 2018, 4:00 pm Oleh Malyi via blfs-support, <

Post by Oleh Malyi via blfs-support
Hello Alex,
your BLFS doesn't have the file stdlib.h from gcc-8.2.0.
You can try rebuild this compiler according its instruction on page
http://www.linuxfromscratch.org/blfs/view/8.3/general/gcc.html
ср, 3 жПвт. 2018 П 19:43 Alex via blfs-support <

Post by Alex via blfs-support
Hi,
I have been trying in vain to get a BLFS (stable v8.3) system up and
running for the last 3 weeks, I have tried 5 times so far and it always
ends up with an error message about missing header files.
LFS (stable v8.3) compiles without any problems at all, but when I start
off with BLFS, packages fail to compile with error messages that
complain about C style header files. I tried hard coding the path to the
C style header file and the compilation continues only to end up with
another missing header file. This behaviour is quite random, a package
that successfully compiled on my first try failed to compile on the
second try and so on.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
make[1]: Entering directory
'/var/tmp/blfs/smartmontools/smartmontools-6.6'
make all-am
make[2]: Entering directory
'/var/tmp/blfs/smartmontools/smartmontools-6.6'
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT smartctl.o -MD -MP -MF .deps/smartctl.Tpo
-c -o smartctl.o smartctl.cpp
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT atacmdnames.o -MD -MP -MF .deps/atacmdname
s.Tpo -c -o atacmdnames.o atacmdnames.cpp
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT atacmds.o -MD -MP -MF .deps/atacmds.Tpo -c
-o atacmds.o atacmds.cpp
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT ataidentify.o -MD -MP -MF .deps/ataidentif
y.Tpo -c -o ataidentify.o ataidentify.cpp
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT ataprint.o -MD -MP -MF .deps/ataprint.Tpo
-c -o ataprint.o ataprint.cpp
mv -f .deps/atacmdnames.Tpo .deps/atacmdnames.Po
g++ -DHAVE_CONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"'
-DSMARTMONTOOLS_SMARTDSCRIPTDIR='"/etc"'
-DSMARTMONTOOLS_DRIVEDBDIR='"/usr/share/smartmontools"' -pipe
-march=native -Wall -W -MT dev_ata_cmd_set.o -MD -MP -MF
.deps/dev_ata_cmd_set.Tpo -c -o dev_ata_cmd_set.o dev_ata_cmd_set.cpp
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from utility.h:36,
from dev_interface.h:23,
from atacmds.h:30,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from utility.h:36,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from utility.h:36,
from dev_interface.h:23,
from atacmds.h:30,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from utility.h:36,
from dev_interface.h:23,
from atacmds.h:30,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
compilation terminated.
compilation terminated.
compilation terminated.
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from /usr/include/c++/8.2.0/stdexcept:39,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:1231: ataidentify.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:1231: ataprint.o] Error 1
make[2]: *** [Makefile:1231: smartctl.o] Error 1
make[2]: *** [Makefile:1231: dev_ata_cmd_set.o] Error 1
make[2]: *** [Makefile:1231: atacmds.o] Error 1
make[2]: Leaving directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
make[1]: *** [Makefile:879: all] Error 2
make[1]: Leaving directory '/var/tmp/blfs/smartmontools/smartmontools-6.6'
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Has anyone encountered this or something similar ? The header file
stdlib.h does exist but, the iostream.h doesn't exist as required by
other packages that failed in previous runs, which is where I get lost
as, I cannot hard code the path and get compilation to proceed. I do not
think it is a good idea to hard code the path to the header files, there
must be something wrong with the system configuration. It has been long
time since I compiled LFS/BLFS or did some C/C++ programming, I need
some directions as to what I should be looking at to troubleshoot this
problem.
Thanks,
Al
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

--
With best regards,
Oleh Malyi
Albufeira
PORTUGAL
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[Paul Rogers via blfs-support]

Post by Alex via blfs-support
LFS (stable v8.3) compiles without any problems at all, but when I start
off with BLFS, packages fail to compile with error messages that
complain about C style header files.

I wonder about your environment. Have you booted with LFS-8.3, or are you in some sort of host environment? You can do either initially, if you're careful. It's probably simplest to boot the new LFS--it's initally a PITA until you get some of the BLFS basics, but after that you should be in the new system. Also check that things like pkg-config are referencing the right files.

[Alex Bosworth via blfs-support]

Yes, I have tried both chroot and native environments, both yiels similar
failures.

I compiled LFS with jhalfs and used the same for BLFS as well. After the
errors, I tried to compile by manually entering commands, same results. I
have double checked and verified the configuration files and environment to
match with the LFS and BLFS books.

I used to be a BLFS user back in 2006-2009,never really had issues. In
2014,I tried compiling LFS on my gaming computer, only to encounter
mysterious errors and segfaults, gave up. Now, on my low budget Asus
laptop, I was quite certain, it was going to be a breeze. It's a bit
daunting and discouraging to encounter repeated failures.

Any suggestions?

Thanks

On Wed, 3 Oct 2018, 5:45 pm Paul Rogers via blfs-support, <

Post by Paul Rogers via blfs-support

Post by Alex via blfs-support
LFS (stable v8.3) compiles without any problems at all, but when I start
off with BLFS, packages fail to compile with error messages that
complain about C style header files.

I wonder about your environment. Have you booted with LFS-8.3, or are you
in some sort of host environment? You can do either initially, if you're
careful. It's probably simplest to boot the new LFS--it's initally a PITA
until you get some of the BLFS basics, but after that you should be in the
new system. Also check that things like pkg-config are referencing the
right files.
--
Paul Rogers
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[Paul Rogers via blfs-support]

Post by Alex Bosworth via blfs-support
laptop, I was quite certain, it was going to be a breeze. It's a bit
daunting and discouraging to encounter repeated failures.
Any suggestions?

Specifically? No. But some general observations.

I find it's never "a breeze"! I don't mean to offend, but I think that was likely your first mistake--something wrong "slipped by" and you are being distracted because it's not working as you expected.

The book has always worked for me. (For upgrading that is, downgrading doesn't because of incompatible instruction sets.) When it hasn't, it has alway been something I messed up or an oversight when I wasn't paying enough attention.

Debugging requires a certain mental approach that's neither common nor easy. It requires one be able to put out of one's mind what's "supposed to happen" and analyze what *has happened* with an "open mind", then ask oneself *what do I know for sure and how do I know it*. There are a lot of assumptions one has made along the way. One can knock them off top-down or bottom-up, but each one must be found and examined. For example, assuming your LFS is properly made when the evidence you're relying on is that it boots and seems to run. I wouldn't be willing to assume the problem is in BLFS.

It's also very important to not get discouraged by repeated failures and dead-ends. The becomes its own distraction that gets in the way. One must approach each foray with the same open mind, care, and essential optimism that it will all work once one finds where one went wrong.

But on the very positive side, when I find where I made my mistake, I always find it was very educational.

[Paul Rogers via blfs-support]

Actually there seems to be a slight inconsistency in the default create
instruction and the comment text just above (664 vs. 664).

I assume that's a typo. Be aware the one that logs user logins, etc., (i.e. auth,authpriv.*) should be 600 or 660.

Beyond that you can set owner and mode in logrotate files, e.g.
/var/log/secure {
create 660 root root
}

[Wolfgang Winkler via blfs-support]

Post by Paul Rogers via blfs-support

Actually there seems to be a slight inconsistency in the default create
instruction and the comment text just above (664 vs. 664).

I assume that's a typo. Be aware the one that logs user logins, etc., (i.e. auth,authpriv.*) should be 600 or 660.
Beyond that you can set owner and mode in logrotate files, e.g.
/var/log/secure {
create 660 root root
}

Thanks for the reply.

So if files that contain user login information (auth*, btmp, wtmp,
faillog and lastlog) should be not world readable - that's not what
seems to be the status neither after finishing LFS nor after BLFS
logrotate installation without changing the books' instructions.

So my original question is still there: What is the recommended
owner/group/permission of the files in /var/log ?

Regards,
Wolfgang

[Michael Shell via blfs-support]

On Wed, 3 Oct 2018 12:18:19 -0600

Post by Alex via blfs-support
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
.
.
Has anyone encountered this or something similar?

Yes, rhubarbpieguy has:

http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-October/080398.html

If rebuilding gcc per Oleh's suggestion works, do let us know.
I'll also post to rhubarbpieguy's thread to link to this one.


Cheers,

Mike Shell

[Michael Shell via blfs-support]

I also found this:

https://www.linuxquestions.org/questions/slackware-14/on-current-qt-include-directory-appears-2x-4175636463/

(referenced by https://trac.wildfiregames.com/ticket/5157)

Check what the environment variable CPLUS_INCLUDE_PATH is being
set to and where it is being set:

echo $CPLUS_INCLUDE_PATH
grep -s CPLUS_INCLUDE_PATH /etc/*

Problems can occur here if a path is duplicated within $CPLUS_INCLUDE_PATH


Cheers,

Mike

[Alex B via blfs-support]

Thanks Michael. That did it. Even though CPLUS_INCLUDE_PATH was not set
and returned empty when echoed, setting explicitly it as "export
CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include" did the trick. I
have the packages compile correctly now, hopefully will finish the build.

I still don't see why there is a need to set that variable, when it is
not being set by jhalfs and can't find any reference to it under /etc
either. The packages should have compiled successfully without the need
for it.

Thanks for all those who tried to help, much appreciated.

Regards,

Alex

Post by Michael Shell via blfs-support
https://www.linuxquestions.org/questions/slackware-14/on-current-qt-include-directory-appears-2x-4175636463/
(referenced by https://trac.wildfiregames.com/ticket/5157)
Check what the environment variable CPLUS_INCLUDE_PATH is being
echo $CPLUS_INCLUDE_PATH
grep -s CPLUS_INCLUDE_PATH /etc/*
Problems can occur here if a path is duplicated within $CPLUS_INCLUDE_PATH
Cheers,
Mike

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Michael Shell via blfs-support]

On Wed, 3 Oct 2018 23:50:15 -0600

"export CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include" did the
trick.
..
I still don't see why there is a need to set that variable, when it is
not being set by jhalfs and can't find any reference to it under /etc
either. The packages should have compiled successfully without the need
for it.

Alex,

I agree with you and Paul here:

On Thu, 04 Oct 2018 16:01:16 -0700

It really does suggest there are further problems in your system.

I found something else that we can compare notes to.
Do a:

unset CPLUS_INCLUDE_PATH
`gcc -print-prog-name=cc1plus` -v

to show the g++ include paths irrespective of what CPLUS_INCLUDE_PATH
was set to. Be sure to use the correct type of quotes in the above
command. Both of the quotes are ` which is on the same key as the tilde ~
on most keyboards. And it seems one has to press ctl-C to get back to
the command prompt after "End of search list." is displayed.

I found this tip at:
https://askubuntu.com/questions/573417/where-are-header-files-for-gcc-located

So, this information from your gcc setup can then be compared to that
of others with recent BLFS systems and then we can see if something
is indeed different.


Cheers,

Mike

[Alex Bosworth via blfs-support]

On Thu, 4 Oct 2018, 8:30 pm Michael Shell via blfs-support, <

Post by Michael Shell via blfs-support
On Wed, 3 Oct 2018 23:50:15 -0600

"export CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include" did the
trick.
..
I still don't see why there is a need to set that variable, when it is
not being set by jhalfs and can't find any reference to it under /etc
either. The packages should have compiled successfully without the need
for it.

Alex,
On Thu, 04 Oct 2018 16:01:16 -0700

It really does suggest there are further problems in your system.

I found something else that we can compare notes to.
unset CPLUS_INCLUDE_PATH
`gcc -print-prog-name=cc1plus` -v
to show the g++ include paths irrespective of what CPLUS_INCLUDE_PATH
was set to. Be sure to use the correct type of quotes in the above
command. Both of the quotes are ` which is on the same key as the tilde ~
on most keyboards. And it seems one has to press ctl-C to get back to
the command prompt after "End of search list." is displayed.
https://askubuntu.com/questions/573417/where-are-header-files-for-gcc-located
So, this information from your gcc setup can then be compared to that
of others with recent BLFS systems and then we can see if something
is indeed different.

Thanks Michael, outfrom from `gcc -print-prog-name=cc1plus` -v - >
-------------
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include
End of search list.
-------------

outfrom from `gcc -print-prog-name=cc1` -v - >
-------------
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
End of search list.
-------------

Regards

Alex

Cheers,

Post by Michael Shell via blfs-support
Mike
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[Michael Shell via blfs-support]

On Thu, 4 Oct 2018 23:06:32 -0600

Post by Alex Bosworth via blfs-support
outfrom from `gcc -print-prog-name=cc1` -v - >
-------------
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/usr/include"
/usr/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
End of search list.

Alex,

My system is still using gcc 7.3.0, so we will need someone using
8.2 or later to compare to your result. However, I think you were
most wise to also include the results for cc1 because the include
file in question, stdlib.h, is a C include, not the C++ include
wrapper of the same name, which loads the stdlib.h C include.

So, the search path for cc1 might be important as well.

Your cc1plus search path looks like mine. However, your cc1 search
path differs from mine in one important respect. On my system,

`gcc -print-prog-name=cc1` -v

lists /usr/include at the very *end*, but yours lists it as the
very *first* one. Note that your

`gcc -print-prog-name=cc1plus` -v

lists /usr/include at the very *end* and this is opposite that of
your cc1. Given the #include_next business, I think this might be
the trouble. Then again, the compile command that failed on your
system was g++ operating on a .cpp file so I don't see how cc1
settings could affect that.

What do the following commands reveal:

echo $CPATH
echo $C_INCLUDE_PATH

On my system, setting

export C_INCLUDE_PATH=/usr/include

will move the /usr/include to the first position of the search order.
$CPATH additions add at the end.

If your system is setting $C_INCLUDE_PATH to /usr/include maybe
that could trigger the problem.

Lastly, what does

find /usr -name "stdlib.h"

reveal on your system?

also remember to
unset C_INCLUDE_PATH
unset CPLUS_INCLUDE_PATH
before running
`gcc -print-prog-name=cc1plus` -v
if you are setting CPLUS_INCLUDE_PATH per our workaround.


Cheers,

Mike

[Paul Rogers via blfs-support]

Post by Alex B via blfs-support
Thanks Michael. That did it. Even though CPLUS_INCLUDE_PATH was not set
and returned empty when echoed, setting explicitly it as "export
CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include" did the trick. I
have the packages compile correctly now, hopefully will finish the build.
I still don't see why there is a need to set that variable, when it is
not being set by jhalfs and can't find any reference to it under /etc
either. The packages should have compiled successfully without the need
for it.
Thanks for all those who tried to help, much appreciated.
Regards,
Alex

Alex, indeed, that would really bother me too! It really does suggest there are further problems in your system. I'd stop until I could figure out why this workaround is necessary.

[Ken Moffat via blfs-support]

Post by Paul Rogers via blfs-support

Post by Alex B via blfs-support
Thanks Michael. That did it. Even though CPLUS_INCLUDE_PATH was not set
and returned empty when echoed, setting explicitly it as "export
CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include" did the trick. I
have the packages compile correctly now, hopefully will finish the build.
I still don't see why there is a need to set that variable, when it is
not being set by jhalfs and can't find any reference to it under /etc
either. The packages should have compiled successfully without the need
for it.
Thanks for all those who tried to help, much appreciated.
Regards,
Alex

Alex, indeed, that would really bother me too! It really does suggest there are further problems in your system. I'd stop until I could figure out why this workaround is necessary.

In an ideal world, yes, we would all stop until we (thought) we
understood how a problem had arrived. But a modern linux desktop
system is a complex beast.

Currently (see the -book list) I'm looking at a problem (tests now
hang in a perl module) which might be related to a newer openssl, but
to me appears to be related to more-recent kernel (4.18) point
releases.

At the moment my interesting systems are unavailable (currently,
updating rustc and firefox as part of my firefox upgrade scripts :
62.0.3 should be fine with rustc-1.25.0 but I was not expecting
another 62 point release and was getting the scripts ready for
63-beta testing.

But when that finishes, I will be trying a developer version of that
module which appears to fix the problem (I want to check that things
work even where they used to with 8.3) and trying to confirm that a
recent stable 4.18 caused the problem seems like a waste of time

(4.18.3 seems ok, 4.18.8 included a CVE fix, 4.18.9 has problems).
But as with everything else in the LFS area - your system, your
choices.

ĸen

[Alex Bosworth via blfs-support]

On Thu, 4 Oct 2018, 6:29 pm Ken Moffat via blfs-support, <

Post by Alex B via blfs-support

Post by Paul Rogers via blfs-support

Post by Alex B via blfs-support
Thanks Michael. That did it. Even though CPLUS_INCLUDE_PATH was not

set

Post by Paul Rogers via blfs-support

Post by Alex B via blfs-support
and returned empty when echoed, setting explicitly it as "export
CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include" did the trick.

I

Post by Paul Rogers via blfs-support

Post by Alex B via blfs-support
have the packages compile correctly now, hopefully will finish the

build.

Post by Paul Rogers via blfs-support

Post by Alex B via blfs-support
I still don't see why there is a need to set that variable, when it is
not being set by jhalfs and can't find any reference to it under /etc
either. The packages should have compiled successfully without the

need

Post by Paul Rogers via blfs-support

Post by Alex B via blfs-support
for it.
Thanks for all those who tried to help, much appreciated.
Regards,
Alex

Alex, indeed, that would really bother me too! It really does suggest

there are further problems in your system. I'd stop until I could figure
out why this workaround is necessary.
In an ideal world, yes, we would all stop until we (thought) we
understood how a problem had arrived. But a modern linux desktop
system is a complex beast.
Currently (see the -book list) I'm looking at a problem (tests now
hang in a perl module) which might be related to a newer openssl, but
to me appears to be related to more-recent kernel (4.18) point
releases.
At the moment my interesting systems are unavailable (currently,
62.0.3 should be fine with rustc-1.25.0 but I was not expecting
another 62 point release and was getting the scripts ready for
63-beta testing.
But when that finishes, I will be trying a developer version of that
module which appears to fix the problem (I want to check that things
work even where they used to with 8.3) and trying to confirm that a
recent stable 4.18 caused the problem seems like a waste of time
(4.18.3 seems ok, 4.18.8 included a CVE fix, 4.18.9 has problems).
But as with everything else in the LFS area - your system, your
choices.

Thanks Ken, I hope the root cause of this anomaly will be found or it
presents itself sooner than later. The work around seems to be working well
for now, perhaps until something else breaks that too, but let's hope not.

Regards

Alex

Post by Alex B via blfs-support
Äžen
--
Well grubbed , old mole!
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[Alex Bosworth via blfs-support]

On Thu, 4 Oct 2018, 5:30 pm Paul Rogers via blfs-support, <

Post by Paul Rogers via blfs-support

Post by Alex B via blfs-support
Thanks Michael. That did it. Even though CPLUS_INCLUDE_PATH was not set
and returned empty when echoed, setting explicitly it as "export
CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include" did the trick. I
have the packages compile correctly now, hopefully will finish the build.
I still don't see why there is a need to set that variable, when it is
not being set by jhalfs and can't find any reference to it under /etc
either. The packages should have compiled successfully without the need
for it.
Thanks for all those who tried to help, much appreciated.
Regards,
Alex

Alex, indeed, that would really bother me too! It really does suggest
there are further problems in your system. I'd stop until I could figure
out why this workaround is necessary.

Thanks Paul. I decided to go ahead as is for now, as I need to have a
running system. Once done, I will start over and see if I could do better.

Alex

Post by Paul Rogers via blfs-support
--
Paul Rogers
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page