Last fixes - remove kludge from RepositoryFixes.mk, have redland
build w/o threads for the while, and some hackery to exclude
pointless code like oosplash from android build.
Don't know how to fix it properly (i.e. use the corresponding
non-deprecated API instead), so just using the pragma to ignore that
warning for now...
Unfortunately gcc 4.2.1 doesn't seem to implement the 'GCC diagnostic
push/pop' pragmas, so we just have to ignore the warning for the
method in question and the rest of the file. But luckily it is the
last method;)
We get this warning when compiling with g++ 4.2.1 from the 10.6
SDK. As far as I see there is no command-line option to get rid of it,
and thus also no pragma to avoid it just for the lines of code in
question.
So to make it compile with -Werror also using this compiler/SDK,
expand the Objective-C message call syntactic sugar into a
objc_msgSend() call instead. That should be equivalent, shouldn't it?
To be specific, 'vcl::PageSyncData' declared with greater visibility
than the type of its field 'vcl::PageSyncData::mActions'
Adding a SAL_DLLPRIVATE to the PageSyncData struct, too, then.
Warning was emitted by g++ 4.2.1 against the MacOSX 10.6 SDK.
* On Mac, nss-config must not emit -rpath-link switch.
* --with-system-nss/-nspr horribly broke in combination with the
routine use of MOZ_ARCH and resulting MOZ_CROSS_COMPILE for Mac,
and the latter appears to be unnecessary for a normal build, anyway,
so is now conditional CREATE_UNIVERSAL_MAC_MOZ_ZIP, in case anybody
still uses the code to create universal moz archives.
* This in turn revealed two issues in moz that have been addressed
with a new macosx_build_fix.patch.
I don't understand what the "universal" byte order thing tries to
say. Sure, Apple's compilers can produce fat binaries, i.e. containing
code for multiple architectures, which I guess might have differing
byte order. But I think the test for an -arch flag being present here
is backwards, surely if you specify -arch i386 for instance, then we
*know* that the byte order is little endian, not "universal".
Anyway, this broke ICU when built against MacOSX SDK 10.6 at least,
the ICU configury used wrong suffix for ICUDATA_NAME, and genbrk
failed in i18npool with a mysterious "can not initialize ICU. status
= U_FILE_ACCESS_ERROR" message.
