mirror of
https://repo.dactyloidae.xyz/Dactyloidae/UXP.git
synced 2026-09-07 00:08:39 +09:00
MoonchildProductions#1251 - Part 23: Allow AMD64 build to work.
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS Setting this up turned out to be easier than I thought it would be. All I had to do was apply these instructions in reverse and add the following to my .mozconfig file: CC="gcc -m64" CXX="g++ -m64" AS="gas --64" ac_add_options --target=x86_64-pc-solaris2.11 export PKG_CONFIG_PATH=/usr/lib/amd64/pkgconfig ac_add_options --libdir=/usr/lib/amd64 ac_add_options --x-libraries=/usr/lib/amd64 Most of these changes were fairly trivial, just requiring me to make a few of the changes I made earlier conditional on a 32-bit build. The biggest challenge was figuring out why the JavaScript engine triggered a segfault everytime it tried to allocate memory. But this patch fixes it: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/web/firefox/patches/patch-js_src_gc_Memory.cpp.patch Turns out that Solaris on AMD64 handles memory management in a fairly unusual way with a segmented memory model, but it's not that different from what we see on other 64-bit processors. In fact, I saw a SPARC crash for a similar reason, and noticed that it looked just like mine except the numbers in the first segment were reversed. Having played around with hex editors before, I had a feeling I might be dealing with a little-endian version of a big-endian problem, but I didn't expect that knowledge to actually yield an easy solution. https://bugzilla.mozilla.org/show_bug.cgi?id=577056 https://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html As far as I can tell, this was the last barrier to an AMD64 Solaris build of Pale Moon.
This commit is contained in:
parent
a5dcb0f82a
commit
0239eb8ac9
8 changed files with 102 additions and 11 deletions
|
|
@ -9,7 +9,12 @@
|
|||
#include "mozilla/MemoryReporting.h"
|
||||
#include "mozilla/IntegerTypeTraits.h"
|
||||
#include "mozilla/Span.h"
|
||||
#ifdef XP_SOLARIS
|
||||
|
||||
// Solaris defines pid_t to be long on ILP32 and int on LP64. I checked in
|
||||
// sys/types.h. AMD64 and SPARC64 builds don't need this fix at all,
|
||||
// while all 32-bit builds do.
|
||||
|
||||
#if defined(XP_SOLARIS) && !defined(__LP64__)
|
||||
#include <unistd.h>
|
||||
#endif
|
||||
|
||||
|
|
@ -590,7 +595,7 @@ public:
|
|||
const char* fmt = aRadix == 10 ? "%d" : aRadix == 8 ? "%o" : "%x";
|
||||
AppendPrintf(fmt, aInteger);
|
||||
}
|
||||
#ifdef XP_SOLARIS
|
||||
#if defined(XP_SOLARIS) && !defined(__LP64__)
|
||||
void AppendInt(pid_t aInteger)
|
||||
{
|
||||
AppendPrintf("%lu", aInteger);
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue