| 1 |
On Mon, Apr 24, 2017 at 02:00:53PM -0700, Ian Zimmerman wrote |
| 2 |
> On 2017-04-24 15:31, Walter Dnes wrote: |
| 3 |
> |
| 4 |
> > I build Pale Moon manually with gcc-5.4.0, and install in my home dir |
| 5 |
> > and it works fine. I can give you manual build instructions and a |
| 6 |
> > quick-n-dirty framework. I believe Pale Moon has problems with the |
| 7 |
> > new ABI. I've been successfully using a custom-built gcc-5.4.0, built |
| 8 |
> > with... |
| 9 |
> > |
| 10 |
> > --with-default-libstdcxx-abi=gcc4-compatible |
| 11 |
> > |
| 12 |
> > You can also force gcc to use the old ABI by including... |
| 13 |
> > |
| 14 |
> > -D_GLIBCXX_USE_CXX11_ABI=0 |
| 15 |
> > |
| 16 |
> > ...in CFLAGS and CXXFLAGS when using a standard gcc-5.4.0. |
| 17 |
> |
| 18 |
> Thanks for your help Walter, but clearly this is not a solution when I'm |
| 19 |
> trying to use Gentoo portage gcc. I already have a well running |
| 20 |
> palemoon built with gcc-4, so what would be the purpose of doing this? |
| 21 |
|
| 22 |
Eventually gcc-4.9.4 will go away. |
| 23 |
|
| 24 |
> Now, your installation may still hold some information for me as I |
| 25 |
> desperately look for a way out. What is your output from: |
| 26 |
> |
| 27 |
> ldd `which palemoon` | grep -F libstdc++ |
| 28 |
|
| 29 |
This is weird... |
| 30 |
|
| 31 |
ldd /home/waltdnes/pm540/palemoon/palemoon | grep -F libstdc++ |
| 32 |
|
| 33 |
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/libstdc++.so.6 (0x00007fa1ba91c000) |
| 34 |
|
| 35 |
But, but, but... Pale Moon's about:buildconfig shows... |
| 36 |
|
| 37 |
|
| 38 |
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 |
| 39 |
|
| 40 |
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 |
| 41 |
|
| 42 |
One way to find out if it works. I'll rebuild pale Moon with the |
| 43 |
native gcc once that machine finishes revdep-rebuild on 31 items, |
| 44 |
followed by "emerge -e @world". |
| 45 |
|
| 46 |
> BTW, do we even know where this bit of information comes from? That |
| 47 |
> error hook is in all the palemoon eclasses, but there is no elaboration |
| 48 |
> of what precisely the problems are or a URL to such description. |
| 49 |
> |
| 50 |
> I am asking because, for a few minutes I had palemoon running with the |
| 51 |
> new libstdc++ loaded (I had to do that to verify for sure that it was |
| 52 |
> loading the new one), and it didn't crash, at least. What if that scary |
| 53 |
> message is just obsolete? |
| 54 |
|
| 55 |
There were issues/crashing reported on the Pale Moon support forum |
| 56 |
when Ubuntu went to gcc-5.3, solved by reverting to 4.9. See thread... |
| 57 |
https://forum.palemoon.org/viewtopic.php?f=37&t=14293 But do note that |
| 58 |
this was the Debian+Ubuntu version maintainer, building on his machine, |
| 59 |
for use on other people's machines, who may not have been up to his |
| 60 |
library versions. If you build on your machine, for your machine, it |
| 61 |
should be internally self-consistent, and you might not run into these |
| 62 |
problems. |
| 63 |
|
| 64 |
-- |
| 65 |
Walter Dnes <waltdnes@××××××××.org> |
| 66 |
I don't run "desktop environments"; I run useful applications |
Archives