Re: [blfs-support] g++ (when including c++ standard headers) is not able to find c standard headers
On Sun, Jul 19, 2020 at 05:02:38PM +0100, Ken Moffat via blfs-support wrote: > On Sun, Jul 19, 2020 at 01:18:50PM +0200, Rielynd Mira wrote: > >That's interesting... > >What do you mean with "to add the missing headers"? As far as I can tell, > >all headers are there... > > Please do not top post. > > With C++ packages (and occasionally too with C) is that what used to s/is that/the problem is that/ > work may now break when the language changes. It might help if I mention that I saw this sort of problem a year or so ago when I tried to build libreoffice. That ships many packages we do not use in naything else , and one of them was broken by a change to the standard used by poppler. The actual error message in that case was deep in the build (even using -j1), but somebody had hit it in gentoo and the problem was ultimately caused by a newer version of poppler. Unfortunately, in that case the only practical workaround was to build an updated version of the package causing the problem (XMLSec1, I think) - until then we had not needed to build that separately. A later release of libreoffice pulled in the fixed version so that it no longer needed to be built separately. But after that, ISTR that another package I build later had a somewhat similar error message and I applied a similar include of one of more C++ headers (*not* C headers!) to whatever was the eventual upstream fix for XMLSec1. ĸen -- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ - Hogfather -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] g++ (when including c++ standard headers) is not able to find c standard headers
On Sun, Jul 19, 2020 at 01:18:50PM +0200, Rielynd Mira wrote: >That's interesting... >What do you mean with "to add the missing headers"? As far as I can tell, >all headers are there... Please do not top post. With C++ packages (and occasionally too with C) is that what used to work may now break when the language changes. >And yep, the exact same source folder failed to compile a day later. >I literally just did a 'make clean' and 'make'. That worked out somehow. >And yeah, I'm quite baffled about that as well.. I have no idea what the >reason for that could be. >I literally just got the idea of recompiling glibc because the only thing >I found regarding that problem I have is that "something with your gcc >might be completely wrong" or "glibc may be at fault". If I rephrase that as "the *standard* implied by you gcc or g++ version is no-longer adequate", perhaps you will understand the problem better. You have not specified which package(s) are affected, nor the errors which resulted. If something used to compile in the past, but now does not, changes in the language standard are often the cause. >No idea... >Funny enough, recompiling and reinstalling glibc worked out without any >kind of crash or hang You were lucky ;-) >10:03 PM, July 16, 2020, "Ken Moffat via blfs-support" >: > > On Thu, Jul 16, 2020 at 09:00:19AM +0200, Rielynd Mira via blfs-support > wrote: > >Hi there, found something extremely weird yesterday. > >When trying to build C++ programs/files, I sometimes get errors >like that: > >/usr/include/c++/10.1.0/cstdlib:75:15: fatal error: stdlib.h: No >such file >or directory >75 | #include_next > >That just appears to happen when including something like >; if I >include the C headers directly, it works fine. > > > I think I've seen similar failures when using a newer version of gcc > (or clang), and maybe also when using a newer version of glibc. > > In each case, the fix has been to add the missing header(s). That's > one of the reasons I hate it when packages or tools change their > default c++ standard, and I have to hope that someone else has > already fixed the packages, and that google can find the fix. > >The main thing that's weird about it: >Yesterday, after I tried out recompiling gcc, everything worked >just fine. >Program built and ran. Though, literally right after I woke up >today, it >didn't work anymore. > > You appear to be saying that the *same* source which compiled > yeaterday no longer compiles today on the same system ? > > A more normal situation would be: yesterday I built several > programs, and of those I had to fix 'foo'. Today I'm getting a > similar problem in 'bar'. That is normal. > >I also tried it with recompiling glibc, which resulted in exactly >the same >thing, and I tried using the '-I' and '-isystem' switches, which >do >absolutely nothing... > >gcc's include search path, glibc's version and 'ldconfig -v' >output from >my system is here: >https://pastebin.com/3qKtNkC8 > >LFS Version I used: Version 20200707-systemd >BLFS Version I used: Version 2020-07-14 - systemd > >I hope that someone is able to help me here to at least understand >what I >did wrong... if anything. > >Thank you. > > Recompiling glibc in case it fixes the problem seems like a > dangerous idea unless you have reason to believe that something > specific in your glibc build was wrong - you will generally need to > reboot after recompiling glibc, and the shutdown can be very unclean > (i.e. the system can hang). > > ĸen > > -- > +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ > - Hogfather > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > >-- >Sent from Yandex.Mail for mobile -- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ - Hogfather -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] g++ (when including c++ standard headers) is not able to find c standard headers
That's interesting... What do you mean with "to add the missing headers"? As far as I can tell, all headers are there... And yep, the exact same source folder failed to compile a day later. I literally just did a 'make clean' and 'make'. That worked out somehow. And yeah, I'm quite baffled about that as well.. I have no idea what the reason for that could be. I literally just got the idea of recompiling glibc because the only thing I found regarding that problem I have is that "something with your gcc might be completely wrong" or "glibc may be at fault".No idea...Funny enough, recompiling and reinstalling glibc worked out without any kind of crash or hang 10:03 PM, July 16, 2020, "Ken Moffat via blfs-support" :On Thu, Jul 16, 2020 at 09:00:19AM +0200, Rielynd Mira via blfs-support wrote:Hi there, found something extremely weird yesterday. When trying to build C++ programs/files, I sometimes get errors like that: /usr/include/c++/10.1.0/cstdlib:75:15: fatal error: stdlib.h: No such fileor directory75 | #include_next That just appears to happen when including something like ; if Iinclude the C headers directly, it works fine. I think I've seen similar failures when using a newer version of gcc(or clang), and maybe also when using a newer version of glibc.In each case, the fix has been to add the missing header(s). That'sone of the reasons I hate it when packages or tools change theirdefault c++ standard, and I have to hope that someone else hasalready fixed the packages, and that google can find the fix.The main thing that's weird about it:Yesterday, after I tried out recompiling gcc, everything worked just fine.Program built and ran. Though, literally right after I woke up today, itdidn't work anymore.You appear to be saying that the *same* source which compiledyeaterday no longer compiles today on the same system ?A more normal situation would be: yesterday I built severalprograms, and of those I had to fix 'foo'. Today I'm getting asimilar problem in 'bar'. That is normal.I also tried it with recompiling glibc, which resulted in exactly the samething, and I tried using the '-I' and '-isystem' switches, which doabsolutely nothing... gcc's include search path, glibc's version and 'ldconfig -v' output frommy system is here:https://pastebin.com/3qKtNkC8 LFS Version I used: Version 20200707-systemdBLFS Version I used: Version 2020-07-14 - systemd I hope that someone is able to help me here to at least understand what Idid wrong... if anything. Thank you.Recompiling glibc in case it fixes the problem seems like adangerous idea unless you have reason to believe that somethingspecific in your glibc build was wrong - you will generally need toreboot after recompiling glibc, and the shutdown can be very unclean(i.e. the system can hang).ĸen-- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ - Hogfather-- http://lists.linuxfromscratch.org/listinfo/blfs-supportFAQ: http://www.linuxfromscratch.org/blfs/faq.htmlUnsubscribe: See the above information page-- Sent from Yandex.Mail for mobile-- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
