This reverts commit 9ff0ee4905068cbc85acf85da1b3ef762b324ed7. Whatever the gold
warnings are exactly, this is apparently not the right fix.
The change to openssl/ExternalProject_openssl.mk caused crashes when LO's
libneon.so, statically linking in LO's libssl.a, started to export symbols like
SSLv23_client_method as global, competing with the same symbol from a system's
libssl.so. See the mail thread starting at
<http://lists.freedesktop.org/archives/libreoffice/2013-June/053119.html>
"strange crash in SSL code while opening some documents."
Whether the change to expat/StaticLibrary_expat.mk caused similar problems is
not clear to me, but it is probably best to revert both to be on the save side,
and see what exactly the gold warning was about and how to fix it the right way
if it ever shows up again.
Note that this doesn't imply it *will* be built; that depends on
configury options and changes to configure.ac.
Change-Id: I5ed531bc8999f49b9e696523226454f99f253882
The internal openssl on 64bit linux was built as linux-generic32, instead of
linux-generi64, which caused crashes later when used. This patch alignes it
with the logic before gbuildization.
Change-Id: I2919a91138e8f33ad50e64728496144bac815321
Add patches and/or tweaks to the following modules:
curl, cppunit, icu, lcms2, libxml2, libxslt, libxmlsec,
lpsolve, nss, openssl, python3
lcms2 has an inconsistency where the .lib and the .dll don't agree on
the .dll name.
openssl gets a honorable mention because apparently it's undocumented
custom build system can build with /MDd if one picks the right
configuration but i couldn't figure out how to do that in an hour of
trying, and just patched the release config instead.
Change-Id: I7854a0fc85247e398d561b4f513d09fe2d1ebb3c
This fixes the following build error here:
ar: creating ../libcrypto.a
ar: cryptlib.o: No such file or directory
make[2]: *** [../libcrypto.a] Error 1
Change-Id: I8f746f4ff44c3797583678e47956363c0cd49829
ExternalProject usually involve a configure and a make
step that produce a bunch of output usually irrelevant
including a large number of warning and other mess.
now that everything is pretty much in tail_build
these output get interleaved with useful output from
the build of the product and actually drown them in a logorrhea
of messy noise.
This store the output of external modules in a log file
and only print them as a whole if the module failed do build.
on a non-verbose build.
Change-Id: I3abfcccd6d16821a9e061a71e031b427cc283647
Reviewed-on: https://gerrit.libreoffice.org/2304
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
...by allowing our special @___... tokens anywhere within an install name,
so that external modules can configure --prefix=/@___... etc. This removes
the need for the special extshl and EXTRPATH=LOADER. Also, a new
OUT2BIN_NONE can be used for external modules where the generated libraries
need the default EXTRPATH=OOO, but generated executables are only used
during the build and such need RPATH=NONE.
Its alternative values as used by OOo is irrelevant to us as we don't
intend to support building using MinGW on Windows itself. To us, MinGW
always means cross-compilation. For us it is enough to look at
$(OS)$(COM), and WNTGCC always implies cross-compilation.
(OOo on the other hand attempts to support use of the Cygwin gcc with
the -mno-cygwin option (which is practically considered an obsolete
option), the normal MinGW compiler (but still from Cygwin), but not
cros-compilation.)
For wntmscx, pass the platform code as VC-WIN64A to the OpenSSL build
mechanism. Add the additional steps described in INSTALL.W64 to
do_ms.bat: generate uptable.asm and assemble it. Avoid a problem with
_vsnprintf by defining _CRT_NON_CONFORMING_SWPRINTFS.
