| Age | Commit message (Collapse) | Author |
|---|
|
This tries to get rid of a lot of cruft from older builds and it
also aims to build as much as possible on Windows.
The firebird-cygwin-msvc-warnings.patch should be optional. It
gets rid of various compiler warnings on Windows, either by
disableing or fixing them:
- fix: D9002 - ignoring unknown option '-fno-rtti'
- fix: D9024 - unrecognized source file type <filename>, object
file assumed
- ign: C4291 - <declaration>: no matching operator delete found;
memory will not be freed if initialization throws an exception
- ign: C4477 - <function>: format string <string> requires an
argument of type <type>, but variadic argument number has
type <type>
And I explicitly got rid of the "win32" handling and simply use
arch depending patches on Windows, which strips additional stuff.
sberg adds: I have no idea how in an upstream macOS build the empbuild
executible in gen/examples should now find @rpath/lib/libfbclient.dylib, as it
does not have an RPATH set. So add an appropriate one in
external/firebird/firebird-macosx.patch.1's patch of
builds/posix/Makefile.in.examples (which needs to know whether we do a Debug or
a Release build; an attempt of using firebird's $(IsDeveloper) for that caused
other failures, see bca0dc97bf3d1348c928bdaf4964524374835823 "Revert
'external/firebird: Pass --enable-developer into configure'", so use LO's
$(ENABLE_DEBUG) and rely on that being exported from LO's make into firebird's
make). Also, the fbclient and Engine12 dylibs now have RPATHs set which we do
not need in LO (where we still stick to our general use of @loader_path), so
drop them in external/firebird/ExternalProject_firebird.mk (even though leaving
them in should be harmless).
Change-Id: Id34bb88900d15f89adda03e34af2ac3d4f6aa085
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105440
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
For one, Clang appears to support __has_feature since at least 3.x times. That
simplifies the first check, from 14955ed91b282ccbb395cb47c6d76e3b42b34748
"external/firebird: Support Clang ASan".
And for another, the second check, from 25764ffd4db0e5db6f9cc9f3da8691e607f48b83
"external/firebird: Better workaround for Clang alignment expectations", can be
simplified now that we no longer support neither Clang < 4 on Linux (since
685aca47da835e80f34b295c5d6389df03d1a8c2 "Bump (Linux) Clang baseline to 5.0.2")
nor Xcode < 9 on macOS (since b4f666f2e677b05cab8395fe7972b45b15f60c3f "Bump
Xcode baseline to 9.3").
But that means we are always setting USE_ASAN when building with Clang now (to
work around certain Clang alignment expectations, regardless of whether or not
we build with -fsanitize=address). Nevertheless, keep the
__has_feature(address_sanitizer) check as a comment, to make this a bit clearer.
Change-Id: Idc9720bd763bc1e00585773ef096202e2a8a6a59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89162
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Also apply sanitizer.patch, because why not.
Also tweak configure to check for dlsym() instead of dlopen();
the situation described in commit
037584cfe5e58bf6807fb0188d245042baa8c1c0 still holds on Fedora 27.
Change-Id: I446fa3e991aec06452f135ab8365702a397c441a
Reviewed-on: https://gerrit.libreoffice.org/55247
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
8ea07101c1613d213fd7cea17f094a947b14cd00 "external/firebird: Work around
operator new alignment violations" had misused DEBUG_GDS_ALLOC to work around
the problem that recent Clang on Linux x86-64 assumes some storage allocated via
Firebird's global operator new replacement to be 16-byte aligned, while Firebird
only provides 8-byte alignment.
This problem now also appears on macOS x86-64, at least with Apple's Clang
version "Apple LLVM version 9.1.0 (clang-902.0.39.1)" from Xcode 9.3 (as well as
with recent plain Clang trunk, towards Clang 7), when building --enable-
optimized. However, while the DEBUG_GDS_ALLOC hack would still cause
ICU_convert_init (workdir/UnpackedTarball/firebird/temp/Release/intl/cv_icu.o)
to not use movaps on erroneously assumed to be 16-byte aligned memory, it would
cause strange failures on macOS (pos being out of bounds in traRpbList::PopRpb,
workdir/UnpackedTarball/firebird/src/jrd/rpb_chain.cpp, in the invocation of
isql during the build of external/firebird) that I haven't tracked down further.
As it happens, the recently added 14955ed91b282ccbb395cb47c6d76e3b42b34748
"external/firebird: Support Clang ASan" provides a different workaround for the
underlying problem that appears to work well on both Linux and macOS x86-64,
reusing USE_ASAN also in these cases to shut down most of Firebird's own memory
management.
I assume that affected Clang are plain Clang >= 4 (as I'd mentioned in my
<https://sourceforge.net/p/firebird/mailman/message/35671804/> "Re: [Firebird-
devel] alloc.h global operator new replacement violating alignment
requirements") and Apple Clang >= 9 (for which __apple_build_version__ is
defined).
Because DEBUG_GDS_ALLOC is no longer passed in from the outside, its setting in
external/firebird/asan.patch can be simplified (cf. commit message of
14955ed91b282ccbb395cb47c6d76e3b42b34748).
(The given scenario in ICU_convert_init involves an allocation of 24 bytes,
where Clang may or may not be allowed to assume 16-byte alignment, see
<http://lists.llvm.org/pipermail/cfe-dev/2018-April/057669.html> "Re: [cfe-dev]
operator new alignment assumptions". However, as reported at
<https://sourceforge.net/p/firebird/mailman/message/35671750/> "Re: [Firebird-
devel] alloc.h global operator new replacement violating alignment
requirements", Firebird only supports 8-byte alignment, which would definitely
be wrong in a similar scenario where the requested allocation was a multiple of
16 bytes.)
Change-Id: I48884f9d008eaeaea369850e24f05b8806f9b676
Reviewed-on: https://gerrit.libreoffice.org/52956
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as needed by some builders, apparently.
Change-Id: I94f3059121d21d55fc7f87d5554bf192f6858e06
|
|
...as needed by some builders, apparently.
Change-Id: I0b7c063ef2c712a6b32aa107ab733a3723b38f99
|
|
...after 14955ed91b282ccbb395cb47c6d76e3b42b34748 "external/firebird: Support
Clang ASan", which was oddly enough only necessary on one machine,
<https://ci.libreoffice.org/job/lo_tb_master_linux/26757/console>, but not on
others. Maybe the best fix overall would be to just not build examples at all,
as is already done in external/firebird/firebird-cygwin-msvc.patch.
Change-Id: I7dd37c93ea5a55cb26a167e52d22a6f50c05494e
Reviewed-on: https://gerrit.libreoffice.org/52779
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
First of all, LD_LIBRARY_PATH must not affect the make executable called for the
firebird build. That would cause problems when that make executable depends on
system versions of dynamic libraries that also happen to be available as LO-
built versions on LD_LIBRARY_PATH:
> make: symbol lookup error: /data/sbergman/lo-san/core/instdir/program/libfreebl3.so: undefined symbol: __asan_option_detect_stack_use_after_return
> make: *** [/data/sbergman/lo-san/core/external/firebird/ExternalProject_firebird.mk:41: /data/sbergman/lo-san/core/workdir/ExternalProject/firebird/build] Error 127
For that, gb_Helper_extend_ld_path is now tunneled to the relevant places in the
firebird build, where executables are called that use firebird's
UnicodeUtil::getConversionICU
(workdir/UnpackedTarball/firebird/src/common/unicode_util.cpp) to dynamically
load icu libraries. (Similar to 3a2818280ad65c3d0aa9e720f62fec571713b2e7
"external/liblangtag: Tunnel LD_LIBRARY_PATH to where it's actually needed".)
Then, what appears to work is to disable firebird's global operators new/delete
(so that ASan's versions kick in).
MemPool::{alloc,release}Raw would still be called at start-up through
Firebird::GlobalPtr<Firebird::Mutex, (Firebird::InstanceControl::DtorPriority)3>
::GlobalPtr() calling Firebird::GlobalStorage::operator new(unsigned long), but
there is already provision to avoid those functions' heavy machinery for the
USE_VALGRIND case.
DEBUG_GDS_ALLOC (which would enable other inopportune overloads of global
operator new/delete) needs to be disabled in a somewhat contorted way, because
8ea07101c1613d213fd7cea17f094a947b14cd00 "external/firebird: Work around
operator new alignment violations" might explicitly set it from the outside,
which we need to undo for ASan builds.
`make check screenshot` encountered one alloc-dealloc-mismatch (already during
building firebird itself) that needs a patch to src/jrd/SimilarToMatcher.h.
Change-Id: I6bb68604095908189259be14440f72d3b23cbd4e
Reviewed-on: https://gerrit.libreoffice.org/52706
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
