shellutil.py: ignore tilde '~' as special character
Currently we don't need the tilde sign defined as a special character
inside the Python wrappers around the autotools files, it's not used any
there and breaks the build of Debian beta versions which uses '~' to
mark the Debian version as 'smaller than'.
Gbp-Pq: Topic debian-hacks
Gbp-Pq: Name shellutil.py-ignore-tilde-as-special-character.patch
Upstream doesn't really care about big endian platforms and so also don't
care about a needed file icudt??b.dat on big endian platforms. Changing
the m4 macro for ICU so the needed file will be depended on the build
platform exported and let later the configure run automatically use the
correct name for the ICU *.dat file so we not only depend on the
prebuild *.dat file for little endian.
The `case foo in ...` loop could be obviously more compressed with only
one case entry for all architectures which are all big endian.
---%<---
case $host in
dnl big endian architectures
hppa-*|m68k-*|...)
--->%---
For more readability the more exclusive extra list of all possible
architectures with big endianness in Debian was choosen.
Gbp-Pq: Topic debian-hacks
Gbp-Pq: Name use-icudt-b-l-.dat-depending-on-architecture.patch
Origin: not yet exist
Bug-Debian: https://bugs.debian.org/859271
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1325771
Applied-Upstream: TBD
All patches have been reviewed by positively by upstream with the
exception of the alignment fixes where upstream wants to use a
C++11 solution instead of the other suggestions I made. This patch
currently uses __attribute__((aligned(4))) to ensure the alignment
is at least 4 bytes. This method is safe and works on gcc and clang
and unlike the suggested alignas() from C++11 does not break on
architectures which require stricter alignment (e.g. alignas(4)
would break on x86_64 while __attribute__((aligned(4))) does not
as it still allows for 8 bytes alignment.
On the Hurd platform the build failed in
js/src/jit/AsmJSSignalHandlers.cpp:131 because of unsupported
mode for reading / writing thead state with following message.
# error "Don't know how to read/write to the thread state via the mcontext_t."
The original patch comes from Richard Brown <rbraun@sceen.net>
https://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2014-March/015565.html
After release of Thunderbird 44 there are additional changes made as the
various configuration files where split into more files.
Gbp-Pq: Topic porting-kfreebsd-hurd
Gbp-Pq: Name FTBFS-hurd-fixing-unsupported-platform-Hurd.patch
Christoph Goehre [Wed, 31 Oct 2012 17:27:07 +0000 (13:27 -0400)]
ipc/chromium: fix #if define() for kFreeBSD and Hurd
The kFreeBSD and Hurd platforms need some other macros to include
the correct needed headers.
Depended on this some minor changes to call the correct functions
also needed. Also the list of the cpp source file for the chromium
things needs to expanded.
The changes is an adoption of the previous dropped patch 'Fix
ipc/chromium on kFreeBSD and Hurd' from the version 17.
Gbp-Pq: Topic porting-kfreebsd-hurd
Gbp-Pq: Name ipc-chromium-fix-if-define-for-kFreeBSD-and-Hurd.patch
Mike Hommey [Thu, 8 Nov 2018 14:50:22 +0000 (14:50 +0000)]
Bug 1505608 - Try to ensure the bss section of the elfhack testcase stays large enough. r=froydnj
In bug 1470701, we added a dummy global variable so that it ends up in
the bss section, making it large enough for two pointers. Unfortunately,
in some cases, the symbol is eliminated by the linker because it is
unused. So we try to ensure it stays there.
Mike Hommey [Sun, 24 Jun 2018 00:02:38 +0000 (09:02 +0900)]
Bug 1470701 - Use run-time page size when changing mapping permissions in elfhack injected code. r?froydnj
When a binary has a PT_GNU_RELRO segment, the elfhack injected code
uses mprotect to add the writable flag to relocated pages before
applying relocations, removing it afterwards. To do so, the elfhack
program uses the location and size of the PT_GNU_RELRO segment, and
adjusts it to be aligned according to the PT_LOAD alignment.
The problem here is that the PT_LOAD alignment doesn't necessarily match
the actual page alignment, and the resulting mprotect may end up not
covering the full extent of what the dynamic linker has protected
read-only according to the PT_GNU_RELRO segment. In turn, this can lead
to a crash on startup when trying to apply relocations to the still
read-only locations.
Practically speaking, this doesn't end up being a problem on x86, where
the PT_LOAD alignment is usually 4096, which happens to be the page
size, but on Debian armhf, it is 64k, while the run time page size can be
4k.
Gbp-Pq: Topic fixes
Gbp-Pq: Name Bug-1470701-Use-run-time-page-size-when-changing-map.patch