Re: [gentoo-user] Re: Argh, palemoon again ** 3 [Was: GCC 5.4.0]

[Bill Kenworthy]

On 25/04/17 06:49, Walter Dnes wrote:
> On Mon, Apr 24, 2017 at 02:00:53PM -0700, Ian Zimmerman wrote
>> On 2017-04-24 15:31, Walter Dnes wrote:
>>
>>> I build Pale Moon manually with gcc-5.4.0, and install in my home dir
>>> and it works fine.  I can give you manual build instructions and a
>>> quick-n-dirty framework.  I believe Pale Moon has problems with the
>>> new ABI.  I've been successfully using a custom-built gcc-5.4.0, built
>>> with...
>>>
>>>  --with-default-libstdcxx-abi=gcc4-compatible
>>>
>>>   You can also force gcc to use the old ABI by including...
>>>
>>>  -D_GLIBCXX_USE_CXX11_ABI=0
>>>
>>> ...in CFLAGS and CXXFLAGS when using a standard gcc-5.4.0.
>>
>> Thanks for your help Walter, but clearly this is not a solution when I'm
>> trying to use Gentoo portage gcc.  I already have a well running
>> palemoon built with gcc-4, so what would be the purpose of doing this?
>
>   Eventually gcc-4.9.4 will go away.
>
>> Now, your installation may still hold some information for me as I
>> desperately look for a way out.  What is your output from:
>>
>> ldd `which palemoon` | grep -F libstdc++
>
>   This is weird...
>
> ldd /home/waltdnes/pm540/palemoon/palemoon | grep -F libstdc++
>
> libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/libstdc++.so.6 (0x00007fa1ba91c000)
>
>   But, but, but... Pale Moon's about:buildconfig shows...
>
>
> gcc 	5.4.0 	-Wall -Wdeclaration-after-statement -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -O2 -march=native -mfpmath=sse -floop-parallelize-all -fpredictive-commoning -ftree-loop-distribution -ftree-vectorize -fno-unwind-tables -fno-asynchronous-unwind-tables -std=gnu99 -fgnu89-inline -fno-strict-aliasing -fno-math-errno -pthread -pipe
>
> c++ 	5.4.0 	-Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -O2 -march=native -mfpmath=sse -floop-parallelize-all -fpredictive-commoning -ftree-loop-distribution -ftree-vectorize -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -D_GLIBCXX_USE_CXX11_ABI=0 -pipe -DNDEBUG -DTRIMMED -g -freorder-blocks -O2 -fomit-frame-pointer
>
>   One way to find out if it works.  I'll rebuild pale Moon with the
> native gcc once that machine finishes revdep-rebuild on 31 items,
> followed by "emerge -e @world".
>
>> BTW, do we even know where this bit of information comes from?  That
>> error hook is in all the palemoon eclasses, but there is no elaboration
>> of what precisely the problems are or a URL to such description.
>>
>> I am asking because, for a few minutes I had palemoon running with the
>> new libstdc++ loaded (I had to do that to verify for sure that it was
>> loading the new one), and it didn't crash, at least.  What if that scary
>> message is just obsolete?
>
>   There were issues/crashing reported on the Pale Moon support forum
> when Ubuntu went to gcc-5.3, solved by reverting to 4.9.  See thread...
> https://forum.palemoon.org/viewtopic.php?f=37&t=14293  But do note that
> this was the Debian+Ubuntu version maintainer, building on his machine,
> for use on other people's machines, who may not have been up to his
> library versions.  If you build on your machine, for your machine, it
> should be internally self-consistent, and you might not run into these
> problems.
>

built by portage after commenting out the "die" in the palemoon-1.eclass
file.

rattus ~ # ldd `which palemoon` | grep -F libstdc++
        libstdc++.so.6 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6 (0x0000003ae0a00000)
rattus ~ #