Age | Commit message (Collapse) | Author |
|
Change-Id: I50a9e8b122250af445c2a1b3d0941d508e027318
Reviewed-on: https://gerrit.libreoffice.org/34528
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
...introduced with b862cbdd345ec57c2595629ded6a3969e1e65d56 "Support MSVC 15.0",
but $(filter ...,) always expands to the empty string, and this is probably what
was intended.
Change-Id: I5865ea13ba3c3d52402bcba48f4f770f6c2b8862
Reviewed-on: https://gerrit.libreoffice.org/34482
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
New compiler changes quite some stuff:
* Compiler detection done based on different registry key
* .NET SDK detection done based on different registry key
* Msbuild installation directory changed
* Merge modules installation directory changed
* SDK number in registry doesn't match the directory name:
(registry key: 10.0.14393, directory name: 10.0.14393.0)
* Compiler, include and library location directories changed
* Architecture specific directory changed: x64 instead of amd64
* Compiler own include directory must be added with -I option
* To force usage of SDK 10 (8.1 is selected per default) new
switch WindowsTargetPlatformVersion is passed to msbuild, to
avoid patching VC project files with this line:
<WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion>
Known issues:
* Firebird is broken: http://paste.openstack.org/show/594333
Change-Id: I148d7932aff43bbbd07bd493504df974726234c2
Reviewed-on: https://gerrit.libreoffice.org/31279
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It's faster to change our code not to rely on -DSOLARIS than to
wait for python developers to remove such nonsense from their public
headers.
Change-Id: I3ab05d41bbb51b91a2add599339ce334b5099330
|
|
- fixes some minor CVEs
- drop python-vc2013.patch.1
- drop python-3.3.3-py17797.patch.1:
the bug was fixed in MSVC2015 runtime so not relevant
- drop python-lsan.patch.0:
fixed upstream
- ubsan.patch.0:
drop hunks that were fixed upstream
- python-3.5.0-tcltk.disable.patch:
merge into msvc-disable.patch.1
Change-Id: I2aecae446539d28eaf3eb64ee67581596019335d
Reviewed-on: https://gerrit.libreoffice.org/33225
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
The original patch caused compilation of x86-ffi64.c to fail, but that
failure was silently ignored by the build.
Change-Id: I93a0cde041b8f9546873d6cc30c1b690da098642
|
|
Thank you Moggi for your help on how to add unicodedata module to Python!
Change-Id: I071e9279d1de4748f9443ac2d624fe925288e408
Reviewed-on: https://gerrit.libreoffice.org/32140
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I26b927345594368f426ae89bfd5b645561d44c10
|
|
Change-Id: I2aa51435d0a15e507d0bf95f98d69fa4cde00b05
|
|
Change-Id: I383a04ea926187263b1d7e11c548817fa9ca3fb6
|
|
Change-Id: I5efe3bafc4f0b97578a75dc1f43e6c130a93bc4a
|
|
libpython3.so is the "ABI compatible" wrapper library around
libpython3.5m.so - it is not actually used by anything in LO right now,
but let's ensure it has RPATH $ORIGIN just in case.
This revealed that the AIX patch in python3 accidentally changed the
SONAME of libpython3.5m.so from upstream's libpython3.5m.so.1.0
on ELF platforms, because the SONAME variable was set in the shell
command but read as a make variable in the next line, which is actually
evaluated earlier.
So rename a few files in packages to use the upstream SONAME.
Change-Id: I3611f75eee62b0993b853230521a2fa41ac5cd9c
|
|
...whose (static) library is called "zlib" instead of just "z".
(I ran into this when trying to do a 32-bit Linux build in a 64-bit environment,
with only very limited 32-bit support installed in the system.)
Change-Id: I9286975917ddf643a22803561677af035e66fb98
Reviewed-on: https://gerrit.libreoffice.org/28964
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
getentropy() and clock_gettime() are new in macOS Sierra (10.12).
Change-Id: I93640bbf20056d925c3116df336aeaebaaffda18
|
|
...in preparation of making them orthogonal
Change-Id: If75b334c954138b3aed4f8d1ac33061a2267ad52
Reviewed-on: https://gerrit.libreoffice.org/27056
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Build on Fedora 24 fails with "Python/thread.o: undefined
reference to symbol 'pthread_key_delete@@GLIBC_2.0'"
Change-Id: If23838722e1cd0220c509d25932ae0539e8da7a1
|
|
Change-Id: Id79898bb4f71103830ad7f74da71fbd5102e4fb5
|
|
Change-Id: Ic0589be9b3769279b201dfd314534a087c7f4309
|
|
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
|