Linux (big endian): ABORT: u_init() failed: ... XPCOMInit.cpp, line 706

[rpxrpx]

Platform: Linux on PPC64 (and all big endian platforms I guess)
Affected Palemoon versions: 28.3 to HEAD (not tested before 28.3)

After a successful compilation starting Palemoon results in these error messages.

Code: Select all

[11877] ###!!! ABORT: u_init() failed: file /usr/src/ralf/UXP/xpcom/build/XPCOMInit.cpp, line 706
[11877] ###!!! ABORT: u_init() failed: file /usr/src/ralf/UXP/xpcom/build/XPCOMInit.cpp, line 706
Speicherzugriffsfehler

The reason is a missing file named icudt58b.dat. It can easily be generated from the little endian version icudt58l.dat. Afterwards the newly generated file needs to be copied into the appropriate directory.

Code: Select all

# in the directory with the source files do:
cd config/external/icu/data
/usr/sbin/icupkg -tb -r confusables.cfu icudt58l.dat
cp icudt58b.dat /usr/src/ralf/pmbuild_28.6.1/dist/bin

I tried to find the code in the mach build system that generates icudt58l.dat, but I failed.
It would be great if the file icudt58b.dat could be generated automatically on big endian platforms.

Any hints or someone can fix this?
Thank you!

By the way: After the other big endian build problems have been fixed by now (28.7 release) this is the last one stopping the out of the box compilation.

[athenian200]

I happened to research this issue while porting UXP to Solaris (though I was primarily focusing on AMD64, there was a lot of SPARC stuff to wade through).

It's a major issue that goes back to Mozilla... no one seems to have come up with a good solution to it, because there was a requirement that the solution had to be testable on a little endian build environment (since that's what most developers will have).

https://bugzilla.mozilla.org/show_bug.c ... 264836#c10

There is some sort of patch for this by Petr Sumbara that's posted in the thread for Solaris SPARC (another big endian platform), would something like that work for your purposes as well, adapted to PPC64 of course?

[Moonchild]

I tried to find the code in the mach build system that generates icudt58l.dat, but I failed.

That is because it's not generated while building -- it's checked into the tree as a binary file (and lives in /config/external/icu/data/)
IIUC, we could check in a big-endian version of this file and simply select the one to use based on the endian-ness of the build target. If not, then using an on-the-fly conversion certainly works; it'll just add a little to the build time. These data files are o.s. independent (except for their endian-ness) so as long as the LE/BE byte ordering is correct it should work on any target.