new GCC compilers do not accept "obsolete and totally removed
in gcc 4.2 and later" -Wno-long-double flag
actually, it used to be Apple-only GCC extension for gcc<=3.3
Change-Id: Ied3320cbd45915682b628c99bb0a168ea4753bb7
Reviewed-on: https://gerrit.libreoffice.org/11819
Reviewed-by: Douglas Mencken <dougmencken@gmail.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
In java9, there is no option for source/target 1.5,
the lowest version is 1.6.
This commit also patches the relevant external libraries
in order to be able to build with build-wide source/target
Change-Id: I68807c973a2a8be2f9b3a6e01243e36cb7110a12
The detection code is wrong for gcc 4.6 and the tr1 code actually
conflicts with the OpenCOLLADA code, because it creates an ambiguity
of shared_ptr in the cpp files.
Additionally most of the headers already use std::shared_ptr or
std::unordered_map.
Change-Id: Ibfe80e45687d34ec6fcd23339fd3f968fae402ba
Reviewed-on: https://gerrit.libreoffice.org/11695
Reviewed-by: Zolnai Tamás <tamas.zolnai@collabora.com>
Tested-by: Zolnai Tamás <tamas.zolnai@collabora.com>
affected: thesaurus usage in a Hungarian document
test case: press Ctrl+F7 on the word "művészegyéniség"
Change-Id: I024568e81265c4ce3e05f718bf9147229416ab73
The firebuild buildsystem calls windres, which depends on cygwin gcc,
use rc.exe so that a windows build without cygwin gcc will succeed.
Change-Id: Ic7719749b3806232912e3eb8b1ede11e6eb3c10c
Reviewed-on: https://gerrit.libreoffice.org/11619
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
The Python build machinery apparently does not use proper autoconfigury to
expand this Info.plist.in file, so can't use @PYTHONFRAMEWORK@ as for the
Info.plist for the framework itself, but have to hardcode LibreOfficePython.
As such I am not sure that Python's way of including an app bundle
inside a framework's Resources subtree is acceptable in the stricter
code signing and Gatekeeper rules that soon will be in effect. Will
see.
Change-Id: I1ef9e7b748d41ec4b32d80e721d5fba5e7a90d18
It should be the basename of the framework. The Python
configury already provides that as @PYTHONFRAMEWORK@.
Change-Id: I116a34c3bcc8f661abe16b2b5cc1b9268ecd2780
This removes ENABLE_NPAPI_INTO_BROWSER while it should keep
ENABLE_NPAPI_FROM_BROWSER (embed flash in LO) intact.
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Conflicts:
extensions/source/nsplugin/source/npshell.cxx
Change-Id: I80a9159a75653c74423d8fdc7c188568d3188e04
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
...otherwise e.g. running CppunitTest_sc_filters_test under -fsanitize=address
complains about ODR violation of 'vtable for orcus::csv::parse_error' exported
from both libsclo.so and libscqahelper.so.
A problem could potentially arise with exceptions thrown from static orcus code
linked into library and intended to be caught in another, but hopefully all such
exceptions are intended to be caught already locally anyway.
Change-Id: Iff5c73d7a2324b457c2e86656c11b18f7ba210f6
