OS.File already only supports UTF-8 paths on non-Windows systems, so this change
makes our different ways of accessing file paths consistent with each other.
This should prevent unexpected crashes in glibc that expect UTF-8.
This resolves#1772.
The original patch handled the grow case but not the shrink case. When the
current and new allocation sizes are in different size classes, jemalloc's
realloc will move the allocation when shrinking, not just truncate the existing
one.
Based on work by Jon Coppeard.
Since these are just interpreted comments, there's 0 impact on actual code.
This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are
a few others scattered around which will be removed manually in a second part.
Correct various pre-processor defines for sparc64 and in mozjemalloc use the JS arm64 allocator on Linux/sparc64.
This corrects build problems opn Linux sparc64 and is in line with bugzilla bug #1275204.
This should do it for all the commits to files I changed, but while I'm in here I could probably go ahead and turn ALL the singular if defined statements into ifdef statements by using grep/find on the tree. On the other hand, perhaps we should do that as a separate issue so that this doesn't become a case of scope creep.
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=577056https://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 is mostly ifdefs, but as you can see, Solaris is actually a lot like Linux. They're both more SysV than BSD at core, and most of the differences have more to do with Solaris not using glibc than anything else.
I still need to audit a lot of these changes and understand why they're needed and what the alternative approaches are. After this patch, most of the core functionality needed to build Solaris is here.
