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.

2 files changed, 9 insertions, 1 deletions

diff --git a/config/external/ffi/moz.build b/config/external/ffi/moz.build
index 3a5478967..01ccd0547 100644
--- a/config/external/ffi/moz.build
+++ b/config/external/ffi/moz.build
@@ -64,13 +64,20 @@ else:
     if CONFIG['INTEL_ARCHITECTURE'] and CONFIG['OS_TARGET'] != 'SunOS':
         DEFINES['HAVE_AS_X86_PCREL'] = True
 
+# Which is why they apparently don't do this anymore on amd64.
+
+    if CONFIG['FFI_TARGET'] == 'X86_64' and CONFIG['OS_TARGET'] == 'SunOS':
+        DEFINES['HAVE_AS_X86_PCREL'] = True
+
     # Don't bother setting EH_FRAME_FLAGS on Windows.
     # Quoted defines confuse msvcc.sh, and the value isn't used there.
     if CONFIG['OS_TARGET'] != 'WINNT':
         # Solaris seems to require EH_FRAME to be writable even on x86.
         # It works fine most of the time and there's no rule against it, 
         # but it causes a lot of weird problems.
-        if CONFIG['FFI_TARGET'] == 'ARM' or CONFIG['OS_ARCH'] == 'SunOS':
+        if CONFIG['FFI_TARGET'] == 'ARM':
+            DEFINES['EH_FRAME_FLAGS'] = '"aw"'
+        elif CONFIG['FFI_TARGET'] == 'X86' and CONFIG['OS_TARGET'] == 'SunOS':
             DEFINES['EH_FRAME_FLAGS'] = '"aw"'
         else:
             DEFINES['EH_FRAME_FLAGS'] = '"a"'
diff --git a/config/external/nspr/pr/moz.build b/config/external/nspr/pr/moz.build
index 84d6e7903..1d2df3099 100644
--- a/config/external/nspr/pr/moz.build
+++ b/config/external/nspr/pr/moz.build
@@ -62,6 +62,7 @@ elif CONFIG['OS_TARGET'] == 'SunOS':
     SOURCES += ['/nsprpub/pr/src/md/unix/solaris.c']
     if CONFIG['CPU_ARCH'] == 'x86_64':
         SOURCES += ['/nsprpub/pr/src/md/unix/os_SunOS_x86_64.s']
+        DEFINES['USE_64'] = True
     elif CONFIG['CPU_ARCH'] == 'x86':
         SOURCES += ['/nsprpub/pr/src/md/unix/os_SunOS_x86.s']
 elif CONFIG['OS_TARGET'] == 'WINNT':