> > Then, in the BatteryManager component, come the actual errors: > > > > In file included from ../../dist/stl_wrappers/new:44:0, > > from /usr/include/c++/7.2.0/bits/exception_ptr.h:40, > > from /usr/include/c++/7.2.0/exception:142, > > from ../../dist/system_wrappers/exception:3, > > from /usr/include/c++/7.2.0/new:40, > > from ../../dist/system_wrappers/new:3, > > from ../../dist/stl_wrappers/limits:38, > > from > > /sources/Pale-moon-27.4.0_Release/dom/battery/BatteryManager.cpp:6: > > ../../dist/include/mozilla/mozalloc.h:207:33: error: ‘bad_alloc’ in > > namespace ‘std’ does not name a type > > void* operator new(size_t size) MOZALLOC_THROW_BAD_ALLOC > > ^ > > That is definitely what happens when the compiler uses a newer c++ > standard. > > > > In Crux, using gcc 6.4, there are neither warnings nor errors, which > > suggests that in LFS, the same problem is giving rise to both. > > > > I'm surprised - I looked at Pale Moon a month or two ago (probably > gcc-7.1) and got lots of errors (building with -j4 or -j8). I > looked at upstream and saw they preferred a gcc-4 version to gcc-5. > > Other reports I found suggested it wouldn't build with gcc-6, so I > gave up on it. > > > I have tried using in LFS the identical source code and mozconfig that the > > Crux package uses, and I get the same errors. As you can see, the header > > referred to in the messages is internal and not a system header, so the > > difference has nothing to do with the overall environment. > > > > Is it possible that simply using a later version of gcc can cause such a > > difference in the outcome? > > Very much. With firefox we've had a lot of different workarounds in > the last year or two, all because of newer gcc versions. In > particular, the c++ standard that g++ defaults to moves on.
I managed to build Pale Moon on my LFS-7.x with gcc-4.9.2, which is the same version of gcc with which the official binary distribution is built. I tried gcc-5.2.0 first (which is still in /usr/bin). The build passed, but the binary was unstable. Also tried gcc-6.1.0 and 7.1.0. They ended up in the same compilation errors you got. Y. Ohashi 2017-09-27 2:59 GMT+09:00 Ken Moffat <[email protected]>: > On Tue, Sep 26, 2017 at 05:01:17PM +0100, Hazel Russman wrote: >> I have been trying to build this program for some time. It builds >> uneventfully in Crux on the same machine. However all my builds in LFS have >> failed in the same way. First comes a long string of warnings of the type: >> >> ../../dist/include/mozilla/mozalloc.h:207:33: note: in expansion of macro >> ‘MOZALLOC_THROW_BAD_ALLOC’ >> void* operator new(size_t size) MOZALLOC_THROW_BAD_ALLOC >> ~~~~~~~~~~~~~~~~~~~~~~~ >> Warning: -Wdeprecated in >> /sources/Pale-Moon-27.4.0_Release/firefox-build-dir/dist/include/mozilla/mozalloc.h: >> dynamic exception specifications are deprecated in C++11 >> ../../dist/include/mozilla/mozalloc.h:201:52: warning: dynamic exception >> specifications are deprecated in C++11 [-Wdeprecated] >> #define MOZALLOC_THROW_BAD_ALLOC_IF_HAS_EXCEPTIONS >> throw(std::bad_alloc) >> > > I treat warnings like that as a side issue, and hope somebody will > care enough to fix them somewhen : there are hundreds, or maybe > thousands, in my normal builds - the last one that affected me was > in one of the perl modules: something had been deprecated for a > while, then in 5.26 it got removed. Fortunately, somebody using > debian unstable had noticed the deprecation when they recently moved > to 5.24 - and provided a fix. > >> Then, in the BatteryManager component, come the actual errors: >> >> In file included from ../../dist/stl_wrappers/new:44:0, >> from /usr/include/c++/7.2.0/bits/exception_ptr.h:40, >> from /usr/include/c++/7.2.0/exception:142, >> from ../../dist/system_wrappers/exception:3, >> from /usr/include/c++/7.2.0/new:40, >> from ../../dist/system_wrappers/new:3, >> from ../../dist/stl_wrappers/limits:38, >> from >> /sources/Pale-moon-27.4.0_Release/dom/battery/BatteryManager.cpp:6: >> ../../dist/include/mozilla/mozalloc.h:207:33: error: ‘bad_alloc’ in >> namespace ‘std’ does not name a type >> void* operator new(size_t size) MOZALLOC_THROW_BAD_ALLOC >> ^ > > That is definitely what happens when the compiler uses a newer c++ > standard. >> >> In Crux, using gcc 6.4, there are neither warnings nor errors, which >> suggests that in LFS, the same problem is giving rise to both. >> > > I'm surprised - I looked at Pale Moon a month or two ago (probably > gcc-7.1) and got lots of errors (building with -j4 or -j8). I > looked at upstream and saw they preferred a gcc-4 version to gcc-5. > > Other reports I found suggested it wouldn't build with gcc-6, so I > gave up on it. > >> I have tried using in LFS the identical source code and mozconfig that the >> Crux package uses, and I get the same errors. As you can see, the header >> referred to in the messages is internal and not a system header, so the >> difference has nothing to do with the overall environment. >> >> Is it possible that simply using a later version of gcc can cause such a >> difference in the outcome? > > Very much. With firefox we've had a lot of different workarounds in > the last year or two, all because of newer gcc versions. In > particular, the c++ standard that g++ defaults to moves on. > > Some of those workarounds were for miscompilation, so not relevant > here, others were because the C++ standard had changed. > > I think at one time we tried --std= in the CFLAGS or CXXFLAGS, but I > forget which standard seemed to help. At other times, inserting > extra headers has been necessary. > > At the moment I'm resigned to using firefox, despite their > continuing efforts to make building harder. If you or anybody else > manages to build Pale Moon with current LFS, and it turns out to be > useful (there was also a comment that its javascript was out of date), > a hint would be welcome. But my impression is that trying to build > Pale Moon with current g++ is only for those who are have the time > to try different fixes, and who feel lucky. > > Unlike firefox and seamonkey, its builders were mostly using old > systems when I looked, hence my surprise that crux managed to build > it on gcc-6.4. Maybe check if they force something in their CFLAGS > or CXXFLAGS. > > ĸen > -- > Truth, in front of her huge walk-in wardrobe, selected black leather > boots with stiletto heels for such a barefaced truth. > - Unseen Academicals > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
