Age | Commit message (Collapse) | Author |
|
Change-Id: I5604aa21981c216e992cbefae043acfd0ab07bbd
Reviewed-on: https://gerrit.libreoffice.org/22626
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I1a6b41bb95bf4edb8e81f2db54624a0892c79bc5
|
|
Change-Id: I279b5df3f9705ca266f2f4efb1e93e59cbbdabd7
Reviewed-on: https://gerrit.libreoffice.org/22603
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
... to avoid calling C:/Windows/system32/{sort,find}.exe, if those
happen to be first in PATH.
On a Windows 7 system, the other conflicts appear to be harmless,
we don't use "more", "expand", "timeout", "whoami".
Change-Id: Iceefeb7ee6725291b04c0eba465991bb1df96b57
Reviewed-on: https://gerrit.libreoffice.org/21175
Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I4f86aba24f2dad14f43effd6e0b291f8f58f1712
|
|
...by again using 'long double' instead of 'double' to "force worst-case
alignment," just like Python 3.3 used to do. This fixes -fsanitize=alignment
failures like
> workdir/UnpackedTarball/python3/Modules/_ctypes/_ctypes.c:2923:10: runtime error: member access within misaligned address 0x6110007af498 for type 'CDataObject' (aka 'struct tagCDataObject'), which requires 16 byte alignment
> 0x6110007af498: note: pointer points here
> ff ff ff ff 01 00 00 00 00 00 00 00 98 98 17 00 90 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
> GenericPyCData_new workdir/UnpackedTarball/python3/Modules/_ctypes/_ctypes.c:2923:10
> PyCFuncPtr_new workdir/UnpackedTarball/python3/Modules/_ctypes/_ctypes.c:3385:29
> type_call workdir/UnpackedTarball/python3/Objects/typeobject.c:908:11
> [...]
during PythonTest_dbaccess_python.
Change-Id: I8cc65823e1bc65807ec30c97a9099462e55c996d
|
|
Change-Id: I2882a97d0e078bd3217170e7906cd41680fbc4a4
Reviewed-on: https://gerrit.libreoffice.org/17360
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I7945eed053a671ad0c755284a372d16083e596b2
|
|
Change-Id: Ie5cd1c0e186920f3b34d3986aa995a5c3be9c58a
|
|
3.5 release is needed for MSVC 14.0 (aka VS 2015) support. Python 3.5
removed build toolchain support for MSVC 2013. Because we still need
to support it, we duplicate the Python directory in externals and
copy old patches and dispatch to this directory for MSVC 2013. Once
the support for MSVC 2013 is dropped on master, this directory can be
removed again.
Change-Id: Idf7bc351239582f583ecbdb53c923cbdcf968089
Reviewed-on: https://gerrit.libreoffice.org/17352
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ie2b338bdd75f26953c758b64711e60b6f5ce9c83
|
|
Change-Id: I8848d042a008c21e407d9610161b5c67d2137a18
|
|
GNU xargs executes the command at least once even if the standard input
is empty, unlike BSD xargs, which causes rm -r to be called with no
arguments ween the find command finds nothing leading to an error.
Adding -f to rm allows buikding with either implementation.
Change-Id: I0df5fcb379d2a5a8b1121594ec1a82d917d80dfc
Reviewed-on: https://gerrit.libreoffice.org/16116
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: Ib589b638a81bfb77fd74da8b15ae7b11cfd2b58b
|
|
Change-Id: I447d1f01c24a934e643077dc271872e850b204bc
|
|
Upgrade to the latest patch from http://bugs.python.org/issue17797
which appears to work even if you invoke from cmd.exe
Change-Id: I85f1cc5ad7d8c059d972ae2a6fd2be1bb5604c2c
|
|
Change-Id: I7b08b7b6376db29b392243f24f6ad3ccf2ee8655
|
|
Change-Id: Iab76060952ae8c1b64d3ff32e5ae8f5212e016b0
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I33976bc96fc78dd0210d9aec6d1ec925f514c7f2
|
|
8a6c5b2f fixed Python build in release mode for x64, but missed to do the
same for the debug mode.
Change-Id: I9762b4089ec95fbd8af12e581fbe8577be5f802a
Reviewed-on: https://gerrit.libreoffice.org/13089
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I608ec429696e6a02aa528b10057d93da63544eb4
|
|
Change-Id: I8f0db23d1f9ba6b9fc3c8b64b32822ba8166428f
|
|
Change-Id: I40d03ab9acb67ab72b9047017452f069ce88fd4b
|
|
Hopefully this should fix up the most important external libraries.
Change-Id: I744cb5a2ce7fafb10852059050cf24589d6ca400
|
|
Change-Id: Ic773b86a1ebaa66a1b0ae236429276f35776deb8
|
|
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
|
|
Change-Id: I9d16f4f0df42ae4b046bc1e4ac4fba95c4b9d785
|
|
...where the intercepted __cxa_throw is found, as otherwise PythonTest_sw_python
fails with
AddressSanitizer CHECK failed: projects/compiler-rt/lib/asan/asan_interceptors.cc:293 "((IndirectExternCall(__interception::real___cxa_throw))) != (0)" (0x0, 0x0)
#0 in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) projects/compiler-rt/lib/asan/asan_rtl.cc:70:3
#1 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:76:5
#2 0x48c3ac in __cxa_throw projects/compiler-rt/lib/asan/asan_interceptors.cc:293:3
#3 0x7f67faec0ef5 in pyuno::createClass(rtl::OUString const&, pyuno::Runtime const&) pyuno/source/module/pyuno_except.cxx:92:9
...
Change-Id: I0cb364eacab49644b426fb62f49bf9d7c8b5090c
|
|
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 those external projects will fail, because with only VS2013 installed
there is no ToolsVersion 4.0 (which is set inside the VC projects files).
http://msdn.microsoft.com/en-us/library/bb383985.aspx
Change-Id: I144ba1ef95372226ebadb082e3a78155cca316fd
|
|
This time use a patch to mangle the project files a bit so that
msbuild likes them.
Change-Id: I1293f4a92164ec6431b96c39f118cbdedbe5fe32
|
|
To build a universal binary in Mac OS X 10.6+ with an Intel processor, it is better to set --with-universal-archs=intel, remember that Rosetta is not installed by default in Mac OS X v10.6 and it is neither included nor supported in Mac OS X v10.7 or later.
If we don't use --with-universal-archs then the configure.ac sets the architectures:
...
UNIVERSAL_ARCHS="32-bit"
if test "`uname -s`" = "Darwin"
then
if test -n "${UNIVERSALSDK}"
then
if test -z "`/usr/bin/file "${UNIVERSALSDK}/usr/lib/libSystem.dylib" | grep ppc`"
then
UNIVERSAL_ARCHS="intel"
fi
fi
fi
...
In Snow Leopard (Mac OS 10.6):
/usr/bin/file /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib: Mach-O universal binary with 4 architectures
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture ppc7400): Mach-O dynamically linked shared library stub ppc
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library stub ppc64
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64
/usr/bin/file /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib: Mach-O universal binary with 3 architectures
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture ppc7400): Mach-O dynamically linked shared library stub ppc
If x86_64 (for OS X 10.8+) or PPC (for OS X 10.5) is only desired then a universal binary is not useful and we don't have to use --enable-universalsdk=${UNIVERSALSDK}.
Change-Id: Ib0578cfdb912fed5a803df3d2e04d2b037cfe13f
Reviewed-on: https://gerrit.libreoffice.org/10249
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
this fixes gcc: error: unrecognized command line option '-arch'
The '-arch' option is part of Apple's extensions to GCC, and it is uncompatible
with "vanilla" GCC from FSF. Also, we're not building "universal binaries".
Change-Id: I44e7c72bbb1dd4be5ac9cdbc4f210aaccea513b4
Reviewed-on: https://gerrit.libreoffice.org/10117
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic4566e8a199d3f31d6d4cb2d3fd41ad7b762c02a
Reviewed-on: https://gerrit.libreoffice.org/10162
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I1cc91bccd288543162b1169ce5621a91a5d4f991
|
|
Change-Id: I281d3dd66a8db8da44cce60bade4a0ee7d1df763
|
|
Change-Id: I40bc9e4c31e270f29cc145b5d2f3544cad586bf7
|
|
as the functions to check for a valid filehandle don't work according to
the documentation. Python in LO-Context is run from GUI anyway, and thus
won't have those hooked up.
Change-Id: I8bc048463b0dc1a25c1b6ba7422623dda110eddc
|
|
...that LeakSanitizer would complain about, causing the check to erroneously fail.
Change-Id: Ieaef38576afd6196d38f395d48fd1bc92b22ddb6
|
|
Change-Id: Ia00d7e52de5edfce09c3a0a8aa4390e3e1582a01
|
|
- remove now obselete patches, which were applied upstream.
- Hack to get MacOS to build
Change-Id: Id68e78e411efc92a46ea9e180f09c390fe5acb4a
Reviewed-on: https://gerrit.libreoffice.org/9311
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
VS2012 did change return value of fileno function, this results in a
crash when run in GUI mode (but not when launching from a shell), as
python tries to access the nonexisting stdin/stdout/stderr
Also explicitly target Windows XP
Change-Id: Ic783713b55453f3c38b2e766a664b7f4678711de
|
|
Change-Id: I72a9ec9569bcd74e212ad98456a76869ac213221
|
|
Change-Id: Ie514017dc186fea4c3f2699e92bfe46706eb6413
|
|
Change-Id: I4f4cecd95f87b9d37fa1b1a270cf554d7707aaa2
|
|
Change-Id: I0cc43cef91e3fcd82a3558a16ab0afbd4d56b141
|
|
liborcus was not building for me with -flto in CFLAGS, I would have to
fix ar somehow.
-flto in LDFLAGS is just to fix the build if the external library does use
another library built by us with -flto: does happen for liborcus and python3.
It's not like we would use -flto for external libraries consistently anyway,
the only exception is icu: no idea why we build with -flto there.
Change-Id: Ia54d619674b8999ce5e4b920ba77b1587c9cf48d
|
|
Change-Id: Ida2dee3b66dd7fbc7942d47a13ce38dda82db866
|
|
Change-Id: I8932febdd39c35f23fb3a89703b69e25302f5678
|