Author Topic: New builds of Thunderbird and SeaMonkey  (Read 4356 times)

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3666
  • Karma: +77/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #30 on: June 12, 2022, 07:53:46 am »
OK, thanks, that looks much the same as my output.
The SeaMonkey build didn't go too bad, ran out of memory at one point, restarted stuff like the browser which had been running for close to a week and restarted. Now it has died linking xul.dll with a couple of missing symbols. I'll redo the build in case the memory allocation problems broke something. Tomorrow before I'll report.
Code: [Select]
91:38.98 weakld: error: Unresolved symbol (UNDEF) '__ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics'.
91:38.98 weakld: info: The symbol is referenced by:
91:38.98     Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.obj
91:38.98 Ignoring unresolved externals reported from weak prelinker.
91:38.98 Error! E2028: __ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics is an undefined reference
91:38.98 file Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.obj(Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.cpp): undefined symbol _ _ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics
91:38.99 make.EXE[4]: *** [xul.dll] Error 1

Paul Smedley

  • Hero Member
  • *****
  • Posts: 1023
  • Karma: +96/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #31 on: June 12, 2022, 11:05:02 am »
Hey Dave,

OK, thanks, that looks much the same as my output.
The SeaMonkey build didn't go too bad, ran out of memory at one point, restarted stuff like the browser which had been running for close to a week and restarted. Now it has died linking xul.dll with a couple of missing symbols. I'll redo the build in case the memory allocation problems broke something. Tomorrow before I'll report.
Code: [Select]
91:38.98 weakld: error: Unresolved symbol (UNDEF) '__ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics'.
91:38.98 weakld: info: The symbol is referenced by:
91:38.98     Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.obj
91:38.98 Ignoring unresolved externals reported from weak prelinker.
91:38.98 Error! E2028: __ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics is an undefined reference
91:38.98 file Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.obj(Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.cpp): undefined symbol _ _ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics
91:38.99 make.EXE[4]: *** [xul.dll] Error 1

I suspect a corrupt obj file from when you ran out of memory.

For the sake of it, I built 9.5.0 - https://smedley.id.au/tmp/gcc-9.5.0-os2-20220612.zip

Cheers,

Paul

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3666
  • Karma: +77/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #32 on: June 12, 2022, 05:34:35 pm »
Well, I did a make clean in thebes and rebuilt, same error. The symbol does seem to be in gfx/thebes/Unified_cpp_gfx_thebes1.obj (the build concats up to 10 source files together before compiling them), not sure if it should be somewhere else too.
Ok, grepping the 9.4.0 obj tree, it is in Unified_cpp_gfx_thebes0.obj as well.
I guess I'll nuke the obj directory and retry.
c++filt says it is "gfxShapedWord* gfxFont::GetShapedWord<unsigned char>(gfxContext*, unsigned char const*, unsigned int, unsigned int, int, bool, int, unsigned int, gfxTextPerfMetrics*)" and the log only shows the usual warnings about it,
Code: [Select]
21:27.42 In file included from Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.cpp:6,
21:27.42                  from Y:/work/cc45-git/obj-sm/gfx/thebes/Unified_cpp_gfx_thebes0.cpp:65:
21:27.42 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h: In constructor 'gfxShapedWord::gfxShapedWord(const uint8_t*, uint32_t, int32_t, int32_t, uint32_t)':
21:27.42 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:1277:72: warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'class gfxShapedText::CompressedGlyph'; use assignment or value-initialization instead [-Wclass-memaccess]
21:27.43  1277 |         memset(mCharGlyphsStorage, 0, aLength * sizeof(CompressedGlyph));
21:27.43       |                                                                        ^
21:27.43 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:700:11: note: 'class gfxShapedText::CompressedGlyph' declared here
21:27.43   700 |     class CompressedGlyph {
21:27.43       |           ^~~~~~~~~~~~~~~
21:27.43 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h: In constructor 'gfxShapedWord::gfxShapedWord(const char16_t*, uint32_t, int32_t, int32_t, uint32_t)':
21:27.57 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:1289:72: warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'class gfxShapedText::CompressedGlyph'; use assignment or value-initialization instead [-Wclass-memaccess]
21:27.57  1289 |         memset(mCharGlyphsStorage, 0, aLength * sizeof(CompressedGlyph));
21:27.57       |                                                                        ^
21:28.13 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:700:11: note: 'class gfxShapedText::CompressedGlyph' declared here
21:28.13   700 |     class CompressedGlyph {
21:28.14       |           ^~~~~~~~~~~~~~~
21:28.90 In file included from Y:/work/cc45-git/mozilla/gfx/thebes/gfxGraphiteShaper.h:9,
21:28.90                  from Y:/work/cc45-git/mozilla/gfx/thebes/gfxGraphiteShaper.cpp:6,
21:28.90                  from Y:/work/cc45-git/obj-sm/gfx/thebes/Unified_cpp_gfx_thebes1.cpp:2:
21:28.90 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h: In constructor 'gfxShapedWord::gfxShapedWord(const uint8_t*, uint32_t, int32_t, int32_t, uint32_t)':
21:28.90 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:1277:72: warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'class gfxShapedText::CompressedGlyph'; use assignment or value-initialization instead [-Wclass-memaccess]
21:29.13  1277 |         memset(mCharGlyphsStorage, 0, aLength * sizeof(CompressedGlyph));
21:29.13       |                                                                        ^
21:29.13 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:700:11: note: 'class gfxShapedText::CompressedGlyph' declared here
21:29.13   700 |     class CompressedGlyph {
21:29.83       |           ^~~~~~~~~~~~~~~
21:29.83 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h: In constructor 'gfxShapedWord::gfxShapedWord(const char16_t*, uint32_t, int32_t, int32_t, uint32_t)':
21:29.83 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:1289:72: warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'class gfxShapedText::CompressedGlyph'; use assignment or value-initialization instead [-Wclass-memaccess]
21:29.83  1289 |         memset(mCharGlyphsStorage, 0, aLength * sizeof(CompressedGlyph));
21:29.91       |                                                                        ^
21:29.91 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:700:11: note: 'class gfxShapedText::CompressedGlyph' declared here
21:29.91   700 |     class CompressedGlyph {
21:29.91       |

These types of warnings are everywhere and was one of the original problems with compiling with GCC 6+ and are due to doing a memset() before the constructor I understand. We now use speciall flags to stop them from being optimized away If I understand correctly
"-flifetime-dse=1 -fno-delete-null-pointer-checks -Wclass-memaccess" on the advice of the GCC people.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3666
  • Karma: +77/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #33 on: June 12, 2022, 08:01:09 pm »
Well, after blowing away the obj directory and redoing, same missing symbol.

Paul Smedley

  • Hero Member
  • *****
  • Posts: 1023
  • Karma: +96/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #34 on: June 12, 2022, 11:36:47 pm »
Well, after blowing away the obj directory and redoing, same missing symbol.
https://bugs.gentoo.org/617690 looks similar - and there's a patch in https://bugs.gentoo.org/617690#c21

They're talking about an older GCC, but who knows?

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3666
  • Karma: +77/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #35 on: June 13, 2022, 01:15:16 am »
Well, after blowing away the obj directory and redoing, same missing symbol.
https://bugs.gentoo.org/617690 looks similar - and there's a patch in https://bugs.gentoo.org/617690#c21

They're talking about an older GCC, but who knows?

The GCC is similar, 6.x-10.x IIRC needed the same fixes. The problem is that patch seems to be for a change between ff55 and ff56.
I'll test it, then I'll take a look at 52ESR where at least the memset() issues should be fixed. Be awhile before testing the new 9.5.0.
At least I did the starter and wiring on the truck today. Solenoid was loose and the wires were rotten, but what a bitch, seems Ford does things the hard way consistently, half a dozen large wires just to feed juice to the starter, with some scarily close to the exhaust.

Paul Smedley

  • Hero Member
  • *****
  • Posts: 1023
  • Karma: +96/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #36 on: June 13, 2022, 01:19:42 am »
Well, after blowing away the obj directory and redoing, same missing symbol.
https://bugs.gentoo.org/617690 looks similar - and there's a patch in https://bugs.gentoo.org/617690#c21

They're talking about an older GCC, but who knows?

The GCC is similar, 6.x-10.x IIRC needed the same fixes. The problem is that patch seems to be for a change between ff55 and ff56.
I'll test it, then I'll take a look at 52ESR where at least the memset() issues should be fixed. Be awhile before testing the new 9.5.0.
At least I did the starter and wiring on the truck today. Solenoid was loose and the wires were rotten, but what a bitch, seems Ford does things the hard way consistently, half a dozen large wires just to feed juice to the starter, with some scarily close to the exhaust.

There's also a patch in https://bugs.gentoo.org/attachment.cgi?id=483002 for FF54

I hate working on cars - I'm too old for that stuff now - loved it when I was younger though :)

Cheers,

Paul

Edit: looking at gfxfont, I think the patch would need to be

Code: [Select]
--- a/gfx/thebes/gfxFont.cpp 2017-06-15 22:52:37.000000000 +0200
+++ b/gfx/thebes/gfxFont.cpp.new 2017-07-10 21:33:43.241262630 +0200
@@ -2612,6 +2612,16 @@
     return sw;
 }
 
+template gfxShapedWord* gfxFont::GetShapedWord(gfxContext *aContext,
+                                               const unsigned char    *aText,
+                                               uint32_t    aLength,
+                                               uint32_t    aHash,
+                                               int32_t      aRunScript,
+                                               bool        aVertical,
+                                               int32_t     aAppUnitsPerDevUnit,
+                                               uint32_t    aFlags,
+                                               gfxTextPerfMetrics *aTextPerf GFX_MAYBE_UNUSED);
+
 bool
 gfxFont::CacheHashEntry::KeyEquals(const KeyTypePointer aKey) const
 {
« Last Edit: June 13, 2022, 01:26:00 am by Paul Smedley »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3666
  • Karma: +77/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #37 on: June 13, 2022, 01:55:00 am »
There's also a patch in https://bugs.gentoo.org/attachment.cgi?id=483002 for FF54

I hate working on cars - I'm too old for that stuff now - loved it when I was younger though :)

Yea, I'm 60 and finding it hard crawling under the truck, especially the getting up part :)

Quote
Cheers,

Paul

Edit: looking at gfxfont, I think the patch would need to be

Code: [Select]
--- a/gfx/thebes/gfxFont.cpp 2017-06-15 22:52:37.000000000 +0200
+++ b/gfx/thebes/gfxFont.cpp.new 2017-07-10 21:33:43.241262630 +0200
@@ -2612,6 +2612,16 @@
     return sw;
 }
 
+template gfxShapedWord* gfxFont::GetShapedWord(gfxContext *aContext,
+                                               const unsigned char    *aText,
+                                               uint32_t    aLength,
+                                               uint32_t    aHash,
+                                               int32_t      aRunScript,
+                                               bool        aVertical,
+                                               int32_t     aAppUnitsPerDevUnit,
+                                               uint32_t    aFlags,
+                                               gfxTextPerfMetrics *aTextPerf GFX_MAYBE_UNUSED);
+
 bool
 gfxFont::CacheHashEntry::KeyEquals(const KeyTypePointer aKey) const
 {

Ok, applied it, went to obj-sm/thebes/gfx, did a make clean and make, then to obj-sm/toolkit/library, did make and xul.dll linked.
Have to finish the build and test and also test with GCC 9.x but at least it did link, so should be good.

Patch ended up as,
Code: [Select]
diff --git a/gfx/thebes/gfxFont.cpp b/gfx/thebes/gfxFont.cpp               4:53p
index f1906a2e1f..5dedc9cd85 100644
--- a/gfx/thebes/gfxFont.cpp
+++ b/gfx/thebes/gfxFont.cpp
@@ -2487,6 +2487,16 @@ gfxFont::GetShapedWord(gfxContext *aContext,
     return sw;
 }

+template gfxShapedWord* gfxFont::GetShapedWord(gfxContext *aContext,
+                                               const unsigned char    *aText,
+                                               uint32_t    aLength,
+                                               uint32_t    aHash,
+                                               int32_t      aRunScript,
+                                               bool        aVertical,
+                                               int32_t     aAppUnitsPerDevUnit,
+                                               uint32_t    aFlags,
+                                               gfxTextPerfMetrics *aTextPerf GFX_MAYBE_UNUSED);
+
 bool
 gfxFont::CacheHashEntry::KeyEquals(const KeyTypePointer aKey) const
 {

Paul Smedley

  • Hero Member
  • *****
  • Posts: 1023
  • Karma: +96/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #38 on: June 13, 2022, 02:16:27 am »
Good news! I knew the line numbers would be out  - but I don't have a local copy of the 45.9 sources yet (checking them out now).

I'm 'only' 47 but my days of car maintenance are definitely over :) Particularly as I bought two new cars when I left GM in 2017 - and modern cars are WAY too hard to work on yourself!

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3666
  • Karma: +77/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #39 on: June 14, 2022, 07:55:54 am »
Well, anyways, if anyone is interested I uploaded the SM 10.3.0 build to https://sourceforge.net/projects/cc-os2/files/

Paul Smedley

  • Hero Member
  • *****
  • Posts: 1023
  • Karma: +96/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #40 on: June 14, 2022, 12:15:47 pm »
Well, anyways, if anyone is interested I uploaded the SM 10.3.0 build to https://sourceforge.net/projects/cc-os2/files/

Glad you got this working Dave!

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 286
  • Karma: +15/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #41 on: June 14, 2022, 04:45:30 pm »
Heh Paul!



I'm 'only' 47 but my days of car maintenance are definitely over :) Particularly as I bought two new cars when I left GM in 2017 - and modern cars are WAY too hard to work on yourself!


I agree 100%.

My loyal 2005 Jeep Liberty crapped out on my birthday last year - I could still do maintenance on it.

Its replacement is an immaculate 2008 Jeep Limited Edition, I bought used - however the new Loyal is a living computer - going to the dealership, its the data transfer module that is plugged in first ................

Upside is the hard drive can hold about 6000 songs, so I'm off the 10"s of cd's cluttering the dashboard.

But still have my 1984 Firebird Trans-Am, the first car I ever bought myself - body fully restored - but need to work on the engine badly as a lot of gaskets are leaking. Perhaps I'll get around to some more restoration this year, but gas prices are a scandal - still completely drive-able without but probably limited this year.

Old loves are always the ones that never quite leave you <sic>.

M
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Mark Szkolnicki

  • Sr. Member
  • ****
  • Posts: 286
  • Karma: +15/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #42 on: June 14, 2022, 04:52:33 pm »
Heh Dave!


Yea, I'm 60 and finding it hard crawling under the truck, especially the getting up part :)


At least you still can get up ............. <grin>

And BTW thanks for the rain .......... had one hell of a thunderstorm last night to start (Thor was throwing around Mjolnir pretty liberally, battling Frost Giants and knocking out power everywhere).

Expecting 135 mm in the next 3 days so we'll be building an ark as well in Alberta, to join you guys in BC.

Best!

M
Vincit Que Se Vincit - "He Who Conquers Self Succeeds"

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3666
  • Karma: +77/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #43 on: June 14, 2022, 05:06:17 pm »
Well, anyways, if anyone is interested I uploaded the SM 10.3.0 build to https://sourceforge.net/projects/cc-os2/files/

Glad you got this working Dave!

It did crash this morning,
Code: [Select]
Call Stack
______________________________________________________________________

   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  B274547A   XUL       0001:0047547A  between PLDHashTable::Clear + A and PLDHashTable::FindFreeEntry - 66  (both in Unified_cpp_xpcom_build0.cpp)

 2DDD2088  11236ED0   XUL       0002:00086ED0  nsTArrayHeader::sEmptyHdr  (in Unified_cpp_xpcom_build1.cpp)

 Lost Stack chain - new EBP below previous

______________________________________________________________________

 Labels on the Stack
______________________________________________________________________

   ESP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 001EF80C  B34AE237   XUL       0001:011DE237  between gfxFontCache::FlushShapedWordCaches + 37 and gfxFontCache::Observer::Observe - 29  (both in Unified_cpp_gfx_thebes0.cpp)
 001EF81C  1F3E1993   LIBCN0    0001:00091993  fmutex.h#138 __um_free_maybe_lock + FF 0001:00091894 (ifree.obj)
 001EF84C  B34E6CD0   XUL       0001:01216CD0  between gfxPlatformFontList::InitFontList + C0 and gfxPlatformFontList::GetFontList - 170  (both in Unified_cpp_gfx_thebes1.cpp)
 001EF88C  B348C48C   XUL       0001:011BC48C  between gfxFcPlatformFontList::InitFontList + 3C and gfxFcPlatformFontList::FindGenericFamilies - 94  (both in gfxFcPlatformFontList.cpp)
 001EF8A8  B3487F00   XUL       0001:011B7F00  gfxFcPlatformFontList::CheckFontUpdates  (in gfxFcPlatformFontList.cpp)
 001EF8AC  B34DA4E0   XUL       0001:0120A4E0  between gfxPlatformFontList::UpdateFontList + 10 and gfxPlatformFontList::SizeOfFontFamilyTableExcludingThis - 10  (both in Unified_cpp_gfx_thebes1.cpp)
 001EF8BC  B55BFB38   XUL       0001:032EFB38  between mozilla::TimeStamp::Now + 18 and mozilla::TimeStamp::ComputeProcessUptime - 28  (both in TimeStamp_posix.cpp)
 001EF8CC  B3487F22   XUL       0001:011B7F22  between gfxFcPlatformFontList::CheckFontUpdates + 22 and nsTHashtable::s_HashKey - 1E  (both in gfxFcPlatformFontList.cpp)
 001EF8D8  000B0CD3   SEAMONKE  0001:000A0CD3  between std::basic_istream::ignore + 19F and __cxxabiv1::__forced_unwind::{typename} - 5D  (both in compatibility.obj)
...

Not sure if just long uptime or something to do with the patch or what. I'll install the dbg files incase it happens again.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3666
  • Karma: +77/-0
    • View Profile
Re: New builds of Thunderbird and SeaMonkey
« Reply #44 on: June 14, 2022, 05:11:11 pm »
Heh Dave!


Yea, I'm 60 and finding it hard crawling under the truck, especially the getting up part :)


At least you still can get up ............. <grin>

And BTW thanks for the rain .......... had one hell of a thunderstorm last night to start (Thor was throwing around Mjolnir pretty liberally, battling Frost Giants and knocking out power everywhere).

Expecting 135 mm in the next 3 days so we'll be building an ark as well in Alberta, to join you guys in BC.

Best!

M

You are welcome to the rain, though it looks like it is leading to a state of emergency with the snow melt. Still grey, wet and cold here, just had to light a fire, which is almost never needed in June. At least the cold has slowed down the snowmelt here.
Good luck and hopefully no flooding