diff options
| author | athenian200 <athenian200@outlook.com> | 2019-10-10 15:38:27 -0500 |
|---|---|---|
| committer | athenian200 <athenian200@outlook.com> | 2019-10-21 04:53:44 -0500 |
| commit | 2f4488521db663520c703a9a836d5549d679266c (patch) | |
| tree | afe79a621a5037846f0089f22e5b59be0a95c8d9 /ipc | |
| parent | 7d65eb2b3a345abe22f42361e00c97da2e968009 (diff) | |
| download | UXP-2f4488521db663520c703a9a836d5549d679266c.tar UXP-2f4488521db663520c703a9a836d5549d679266c.tar.gz UXP-2f4488521db663520c703a9a836d5549d679266c.tar.lz UXP-2f4488521db663520c703a9a836d5549d679266c.tar.xz UXP-2f4488521db663520c703a9a836d5549d679266c.zip | |
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.
Diffstat (limited to 'ipc')
| -rw-r--r-- | ipc/chromium/src/base/message_pump_libevent.cc | 2 | ||||
| -rw-r--r-- | ipc/chromium/src/third_party/libevent/solaris/event2/event-config.h | 4 |
2 files changed, 1 insertions, 5 deletions
diff --git a/ipc/chromium/src/base/message_pump_libevent.cc b/ipc/chromium/src/base/message_pump_libevent.cc index daba7c2fe..20d529707 100644 --- a/ipc/chromium/src/base/message_pump_libevent.cc +++ b/ipc/chromium/src/base/message_pump_libevent.cc @@ -24,7 +24,7 @@ #include "mozilla/UniquePtr.h" // This macro checks that the _EVENT_SIZEOF_* constants defined in -// ipc/chromiume/src/third_party/<platform>/event2/event-config.h are correct. +// ipc/chromium/src/third_party/<platform>/event2/event-config.h are correct. #if defined(_EVENT_SIZEOF_SHORT) #define CHECK_EVENT_SIZEOF(TYPE, type) \ static_assert(_EVENT_SIZEOF_##TYPE == sizeof(type), \ diff --git a/ipc/chromium/src/third_party/libevent/solaris/event2/event-config.h b/ipc/chromium/src/third_party/libevent/solaris/event2/event-config.h index 73000106b..cc4fb1eb1 100644 --- a/ipc/chromium/src/third_party/libevent/solaris/event2/event-config.h +++ b/ipc/chromium/src/third_party/libevent/solaris/event2/event-config.h @@ -417,11 +417,7 @@ #define _EVENT_SIZEOF_LONG_LONG 8 /* The size of `pthread_t', as computed by sizeof. */ -#ifdef __LP64__ -#define _EVENT_SIZEOF_PTHREAD_T 8 -#else #define _EVENT_SIZEOF_PTHREAD_T 4 -#endif /* The size of `short', as computed by sizeof. */ #define _EVENT_SIZEOF_SHORT 2 |