| 1 |
On 25/04/17 05:17, Ian Zimmerman wrote: |
| 2 |
> On 2017-04-24 15:31, Walter Dnes wrote: |
| 3 |
> |
| 4 |
>>> Or do I have to mask gcc-5 until palemoon is fixed (and will it ever be?) |
| 5 |
> |
| 6 |
> [...] |
| 7 |
> |
| 8 |
>> I believe Pale Moon has problems with the new |
| 9 |
>> ABI. I've been successfully using a custom-built gcc-5.4.0, built |
| 10 |
>> with... |
| 11 |
>> |
| 12 |
>> --with-default-libstdcxx-abi=gcc4-compatible |
| 13 |
> |
| 14 |
> BTW, do we even know where this bit of information comes from? That |
| 15 |
> error hook is in all the palemoon eclasses, but there is no elaboration |
| 16 |
> of what precisely the problems are or a URL to such description. |
| 17 |
> |
| 18 |
> I am asking because, for a few minutes I had palemoon running with the |
| 19 |
> new libstdc++ loaded (I had to do that to verify for sure that it was |
| 20 |
> loading the new one), and it didn't crash, at least. What if that scary |
| 21 |
> message is just obsolete? |
| 22 |
> |
| 23 |
|
| 24 |
Just comment out the "die" in the plaemoon-1.eclass and let it build. I |
| 25 |
actually emerge -c'd it first but I think that was unnecessary. Its |
| 26 |
stable after building with 5.4 for a few hours use so far. |
| 27 |
|
| 28 |
The problem isn't 4.9 vs 5.4, but mixing the different gcc ABI's |
| 29 |
involved. Once the conversion is over, its fine. (info from an earlier |
| 30 |
email and then some followup readings) |
| 31 |
|
| 32 |
Also, pipe the output of revdep-rebuild to a file, edit the file and run |
| 33 |
the build from that so you can control which packages build, and can |
| 34 |
take care of failures without starting from scratch. |
| 35 |
|
| 36 |
BillK |
Archives