summaryrefslogtreecommitdiff
path: root/external/firebird
AgeCommit message (Collapse)Author
2022-11-21macOS (janitor): remove workarounds for no longer supported SDKsChristian Lohmaier
since we won't accept anything lower than 10.14 on master (and 10.13 on libreoffice-7-4 branch), we don't need those quirks anymore. Change-Id: Ibc71a2ce7a0dc60769d03d477991b48fc99d534d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143040 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2022-10-20external/firebird: Adapt more configure checks to C99Stephan Bergmann
...similar to f6be6cd82bd84f13d2a597ceb62181111ae0eb80 "external/firebird: Missing include in configure check" and 7e1ff1cee5dd203df679d584512930fb21b97f6e "external/firebird: Implicit int in configure check". With recent Clang on Linux it had still failed to detected > configure:20511: checking for working sem_init() [...] > conftest.c:166:2: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] > main () { > ^ > int > conftest.c:168:3: error: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > exit(sem_init(&s,0,0)); > ^ > conftest.c:168:3: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit' and > configure:21256: checking for native large file support [...] > conftest.c:167:5: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] > main () { > ^ > int > conftest.c:168:5: error: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > exit(!(sizeof(off_t) == 8)); > ^ > conftest.c:168:5: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit' And at least the former, which erroneously suppressed setting WORKING_SEM_INIT, sporadically caused CppunitTest_dbaccess_hsql_binary_import to SIGABRT for me at > #10 0x00007f087fce37fc in __GI_abort () > #11 0x00007f085a7e32e8 in Firebird::system_call_failed::system_call_failed(char const*, int) (this=0x55fbb11e5650, syscall=0x7f085a19ac06 "sem_open", error_code=17) at workdir/UnpackedTarball/firebird/src/common/fb_exception.cpp:244 > #12 0x00007f085a7e33ba in Firebird::system_call_failed::raise(char const*) (syscall=0x7f085a19ac06 "sem_open") at workdir/UnpackedTarball/firebird/src/common/fb_exception.cpp:255 > #13 0x00007f085a81ff4e in Firebird::SignalSafeSemaphore::init() (this=0x55fbb1268c80) at workdir/UnpackedTarball/firebird/src/common/classes/semaphore.cpp:138 > #14 0x00007f085a38ee85 in Firebird::SignalSafeSemaphore::SignalSafeSemaphore() (this=0x55fbb1268c80) at workdir/UnpackedTarball/firebird/src/common/classes/semaphore.h:156 > #15 0x00007f085a38c931 in (anonymous namespace)::MappingIpc::MappingIpc(Firebird::MemoryPool&) (this=0x55fbb1268bf0) at workdir/UnpackedTarball/firebird/src/jrd/Mapping.cpp:602 > #16 0x00007f085a38176b in Firebird::GlobalPtr<(anonymous namespace)::MappingIpc, (Firebird::InstanceControl::DtorPriority)2>::GlobalPtr() (this=0x7f085a93e780 <(anonymous namespace)::mappingIpc>) at workdir/UnpackedTarball/firebird/src/common/classes/init.h:143 > #17 0x00007f085a38d270 in __cxx_global_var_init.15(void) () at workdir/UnpackedTarball/firebird/src/jrd/Mapping.cpp:901 [...] > #32 0x00007f085bb37626 in ModuleLoader::loadModule(long*, Firebird::StringBase<Firebird::PathNameComparator> const&) (status=0x7ffd9f8b42a0, modPath=...) at workdir/UnpackedTarball/firebird/src/common/os/posix/mod_loader.cpp:95 [...] Change-Id: I082be878d95a020a7c419d6852614b711754cc23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141549 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-09-17external/firebird: Fix -Wincompatible-function-pointer-typesStephan Bergmann
...after Clang 16 trunk <https://github.com/llvm/llvm-project/commit/af01f717c48f0fd2481600ed6c00441763365b62> "Default implicit function pointer conversions diagnostic to be an error" Change-Id: Ibe06a94f45010efdeaf0c05a661f269e7a07d561 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140095 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-09-16external/firebird: Work around std::auto_ptr gone from C++17Stephan Bergmann
...which started to be an issue when building with recent Clang 16 trunk after <https://github.com/llvm/llvm-project/commit/3e99b8d947ac024831e59be2b604ac67a24fed94> "C++/ObjC++: switch to gnu++17 as the default standard" against libc++: > src/cloop/Main.cpp:31:12: error: no member named 'auto_ptr' in namespace 'std' > using std::auto_ptr; > ~~~~~^ (Recent versions of GCC similarly default to C++17, but libstdc++ by default still provides auto_ptr even for C++17.) Adding -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR to CXXFLAGS didn't work, though, as firebird apparently only honors CXXFLAGS during the configure step, but not in its makefiles. So instead add it directly to CXX. (Adding /all/ the CXXFLAGS to CXX caused issues at least on Windows, where <https://ci.libreoffice.org/job/gerrit_windows/135851/> failed with > Main.cpp > C:\cygwin\home\tdf\jenkins\workspace\gerrit_windows\workdir\UnpackedTarball\firebird\extern\cloop\src\cloop\Expr.h(25): fatal error C1034: string: no include path set etc. This probably needs a general clean-up, and the other *FLAGS passed into the firebird build system might have a similar issue.) Change-Id: Idf0a5243938fddfb8348cc960074e60dea775650 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139932 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-08external/firebird: Implicit int in configure checkStephan Bergmann
...so that with Clang 15 trunk after <https://github.com/llvm/llvm-project/commit/2cb2cd242ca08d0bbd2a51a41f1317442e5414fc> "Change the behavior of implicit int diagnostics" the check now failed to compile with > configure:21471: checking alignment of long [...] > conftest.c:166:2: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] with consequences the same as in f6be6cd82bd84f13d2a597ceb62181111ae0eb80 "external/firebird: Missing include in configure check" (so rename the existing configure-include.patch, as it now covers various kinds of C99 violations) Change-Id: I64e7c13945a3ede3900cc6a84da575e35bdce953 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133994 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-01try to use also proper debug LDFLAGS for externals librariesLuboš Luňák
This is basically ea68de2968c0dbcd8e7549435e829db06795c16d but for LDFLAGS. A number of external libs cannot use this because their libtool mishandles -fuse-ld. Change-Id: Idee379eb0a3afb475b536519ee3de064b4e218f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133639 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-25external/firebird: Missing include in configure checkStephan Bergmann
...so that with Clang 15 trunk after <https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626> "[C11/C2x] Change the behavior of the implicit function declaration warning" the check now failed to compile with > configure:21471: checking alignment of long [...] > conftest.c:177:3: error: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > exit((int)&((struct s*)1024)->b - 1024); > ^ > conftest.c:177:3: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit' and an exit code of 1 from the compiler invocation, which the check than silently mistook as an alignment requirement of 1. (Which then caused the somewhat obscure fallout of > workdir/UnpackedTarball/firebird/src/gpre/msc.cpp:463:10: runtime error: member access within misaligned address 0x7f59d8e68196 for type 'gpre_sym', which requires 8 byte alignment while building ExternalProject_firebird with UBSan.) The corresponding "checking alignment of double" a few lines further down had already been modified in ccd0e5f445d4a7d0e7aca6c23c02c61bf14510b2 "Make firebird build for macOS on arm64", but without stating what actual problem (if any) it fixed. I thus moved that patch into the new external/firebird/configure-include.patch too, to have them grouped together. (An alternative fix could be to replace the use of exit with return from main in those configure checks.) Change-Id: Iefa02a06d45c83add5f56fad5d726aaecee6d815 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133368 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-12use gb_DEBUGINFO_FLAGS consistently in gbuild ExternalProject'sLuboš Luňák
A number of them didn't use it at all, others had it hand-written in various ways. Change-Id: Iaf86325f9cdc032926bac917dc3eef4e34661544 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132818 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-02-25Drop support for $host_os = 'macos*', in addition to 'darwin*'Stephan Bergmann
...which had originally been added with baab4f890c8ac99d1b8dab5790fbb7ab949100ab "Initial WIP steps for building for macOS on Apple Silicon" for unclear reasons (just stating "use 'darwin' (or 'macos')" in the commit message), and then further improved with 5a0991c9cd60b6ab10fe0665511e7749a0c0ecc2 "mac: allow cross compiling with host/build x86_64-apple-macos". But it turns out that manually specifying --host or --build =...-macos rather than =...-darwin has issues as discussed in the comments at <https://gerrit.libreoffice.org/c/core/+/130353> "icu: override platform flags for MacOS build", and which can hopefully be avoided by not allowing =...-macos in the first place, and rather forcing people to specify =...-darwin. Change-Id: Ib100b7270250083eba4146430e967073a8cbca46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130505 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-31externals: always provide platform configure flagsJan-Marek Glogowski
No idea why we just provided the platform flags when cross- compiling. In the curious case, where the host platform is detected as x86_64-pc-mingw32 per default and we actually want to override it with x86_64-pc-cygwin, we don't do a cross compile, but must override the host platform. But there is additional special handling needed for the omitted cross-platform build in the special case of --host=i686-pc-cygwin and --build=x86_64-pc-cygwin, where we deliberatly ignore cross building; Windows is already a slow build, so try to keep this optimization (AMD64 can execute x86 binaries). There is the theoretical case, where the externals config.guess would have detected something else and that "magically" even worked, while the LO detected triplet would fail, but this should be fixed in the external in any way. Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-09-07exernal/firebird: extern/cloop: Missing dependencies of compilations on...Stephan Bergmann
...output directories Change-Id: Iaa2b750a12e3df078b46e5bb4feeafc926e11165 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121741 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-06tdf#144340: fix FB configure on WindowsMike Kaganski
./configure runs on Windows, and sets value of FB_ALIGNMENT, a define that affects the layout of FB's sort memory pool. Trying to include <semaphore.h> fails on Windows; the test in ./configure considers error value (equal to 2) as the value of the alignment (which should be 4 or 8 depending on arch). This makes the memory misaligned, chunks overlapping and re-written during the sort, memory corrupt, and so on. Removing the include (which is documented in a commit adding a similar include [1] to be needed for m68k) fixes detection. Additionally this cleans up the code added to config.h.in from autoconfig_msvc.h, because the former is auto-generated during configure, and the values get re-written in all occurrences of respective defines anyway. [1] https://github.com/FirebirdSQL/firebird/commit/7ba46163c74211ce4bf1051ee9998db58cb2f396 Change-Id: I8cdc5c764385a04efd130af09138149c748341fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121753 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-03No need to check DBGUTIL speciallyMike Kaganski
... as discussed in comments to https://gerrit.libreoffice.org/c/core/+/121470 Change-Id: I9be45e2157972156ab7c2aac820b69aa894cacfe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121553 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-03Make sure to use debug options for firebird in debug modeMike Kaganski
Change-Id: I358bd2013387e9fb341d92764f29767d6c0c2cb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121470 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-02tdf#144172: patch FB to use per-process LOCK directoriesMike Kaganski
As discussed at https://github.com/FirebirdSQL/firebird/pull/6937: > > But as well, we may just use process id instead of session id in > > the ConfigStorage::ConfigStorage creating filename. That would be > > even better, fitting better into our per-process temp dir policy. > I tend to agree with you here. It looks safe assuming LO uses > SuperServer only. Let's not replace the session id with process id, but instead append process id after session id, to avoid (unlikely?) accidental overlap of process id and session id, which would produce the same name as already used by, say, isql tool. Change-Id: Ibce8a8c75d405aae3e8949e7daf2476accdff22b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121457 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-02-19tdf#140332: Can't use System V semaphores in a sandboxed macOS processTor Lillqvist
See https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html , "Note: System V semaphores are not supported in sandboxed apps". So use POSIX semaphores instead. Change-Id: I37c910cf13b868ab15fe31f90e42d24a9a24eeb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111239 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-28mac: allow cross compiling with host/build x86_64-apple-macosChristian Lohmaier
apple silicon supports to cross compile without special build-tools/full cross-compiling setup, so just always pass the build/host for firebird. firebird and nss don't recognize the -macos specifier, so substitute it by -darwin to make those happy… Change-Id: I953317fc87da2a20dc91acd88c8528796c3b2a69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110093 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-01Removed executable bits from patch fileAndrea Gelmini
Change-Id: I6cbfbfe32fb1d70cd8f73add0c2f6a63117e7f4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108560 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-12-29external/firebird: Fix MSVC /Zc:strictStringsStephan Bergmann
> C:/lo/core/workdir/UnpackedTarball/firebird/src/auth/trusted/AuthSspi.cpp(112): error C2664: 'SECURITY_STATUS (SEC_CHAR *,SEC_CHAR *,unsigned long,void *,void *,SEC_GET_KEY_FN,void *,PCredHandle,PTimeStamp)': cannot convert argument 2 from 'const char [5]' to 'SEC_CHAR *' > C:/lo/core/workdir/UnpackedTarball/firebird/src/auth/trusted/AuthSspi.cpp(112): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) Not sure why this only started to hit my build now. Change-Id: Idea0a8a2abaafe17183323a31f29173bd71fbeec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-07external/firebird: clang-cl needs -march=x86-64-v2 nowStephan Bergmann
...to avoid > C:/lo/core/workdir/UnpackedTarball/firebird/src/common/CRC32C.cpp(41,10): error: always_inline function '_mm_crc32_u8' requires target feature 'sse4.2', but would be inlined into function 'CRC32C' that is compiled without support for 'sse4.2' > return _mm_crc32_u8(hash_value, *value); > ^ etc. With <https://github.com/FirebirdSQL/firebird/commit/ 52d9a05a0f3d811a9de7f15956ee9286d5711648> "Backport from master", that code appeared on the B3_0_Release branch only after R3_0_1, so was not present in our Firebird-3.0.0.32483-0.tar.bz2 before 86744f03992213af162df6954313c9f9e44e3a0a "firebird: update to 3.0.7". This is apparently about the SSE4.2 CRC32 instruction. Not sure how this works in the MSVC build, whether it implicitly generates code targeting SSE4.2 (<https://docs.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-160> "/arch (x64)" does not mention any switch to explicitly enable it), or whether its _mm_crc32_u* intrinsics would be smart enough to generate code that also works when SSE4.2 is not available at runtime. Change-Id: I893733eb079e6c0eb8b685a55ce09e1fdcd2eda2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107334 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03external/firebird: extern/cloop: Missing dependency of $(BIN_DIR)/cloop...Stephan Bergmann
...on $(BIN_DIR) Change-Id: I649f2eaafb0e7160f7092a652c38193975fb5982 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107163 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-02external/firebird: Fix checks for null HANDLE in Windows-only codeStephan Bergmann
Change-Id: I428bbdae91eaf69df43ae054a95e8da3fb1aa7dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107056 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-27Fix Firebird build on macOS on arm64Tor Lillqvist
Must set RAW_DEVICES_FLG=N for this architecture, too. Make the prefix.darwin_arm64 match the x86_64 one. Don't bother defining ARM64, just check for __aarch64__. Change-Id: I9de67493cb159ce97a46cdd1974b04753518c703 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106716 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-11-26New UBSan failures with Firebird 3.0.7Stephan Bergmann
While building ExternalProject_firebird: For one, the ICU UCHAR_TYPE mismatch > workdir/UnpackedTarball/firebird/src/intl/cs_icu.cpp:66:30: runtime error: call to function ucnv_fromUChars_68 through pointer to incorrect function type 'int (*)(UConverter *, char *, int, const unsigned short *, int, UErrorCode *)' from 61411db9f719d793f0665a4d278e0748e8fcd75f "external/firebird: ICU_UCHAR_TYPE breaks -fsanitize=function" returned in a slightly different form. Instead of passing in the problematic UCHAR_TYPE macro from external/firebird/ExternalProject_firebird.mk, Firebird now set it internally in src/common/common.h. And for another, it grew a new invalid-shift-base at > workdir/UnpackedTarball/firebird/src/yvalve/gds.cpp:2564:33: runtime error: left shift of negative value -1 (And beyond that there were no further new ASan/UBSan issues with a full `make check screenshot`.) Change-Id: Ie15cf6bde2df7dc784fec89045026f71747aa0bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106477 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-26firebird: update to 3.0.7Julien Nabet
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>
2020-11-26Revert "external/firebird: Pass --enable-developer into configure"Stephan Bergmann
This reverts commit 823059c8f046927c3193da5acd78053f3269b753. It was meant as a prerequisite for a macOS-specific fix in patch set 19 of <https://gerrit.libreoffice.org/c/core/+/105440/19> "firebird: update to 3.0.7", but caused both the Jenkins Windows build of that Gerrit change's patch set, as well as vmiklos' Linux build based on 823059c8f046927c3193da5acd78053f3269b753 to fail with "Could not find acceptable ICU library" messages. The reasons have not been tracked down, but are presumably because workdir/UnpackedTarball/firebird/gen/Makefile starts to execute some more recipe lines based on IsDeveloper being "Y". Lets seek another fix for the macOS issue instead. Change-Id: I4bd6ad38bc0fc0ef2debd5ef55131bccbff54ebc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106675 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-25external/firebird: Pass --enable-developer into configureStephan Bergmann
...instead of merely forcing the Make target to Debug. That way, a future patch set of in-progress <https://gerrit.libreoffice.org/c/core/+/105440/16> "firebird: update to 3.0.7" will be able to know in the gen/examples sub- directory Make that the top-level Make was targeting Debug, not Release. (Which it will presumably need to know to fix the macOS build.) Change-Id: I57f90f66b4739b9d2cb5c33d79fcb87090c820bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106588 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-21firebird: build fixes (incl. parallel build)Jan-Marek Glogowski
The main idea is to get rid of the "unset MAKEFLAGS". AFAI can see, the whole CPU stuff isn't used anymore. So we can drop the whole FB_CPU_ARG handling. Since LO doesn't use any of make's implicit rules, the build breaks, but luckily it just requires a single rule for the btyacc build - just a Firebuild build tool. Then there is the whole broken handling of LIBTOMMATH and LIBATOMIC_OPS already in LO's configure.ac. I don't know if any internal build of Firebird with these as system libs would work. I guess people either have a system Firebird or also build with internal libtommath and libatomic_ops. This fixes just the obvious errors. I didn't try to build it, so there might still be typos (TBH I thought hard about just dropping the system build of these libraries, after seeing the broken configure.ac). And I'm not sure our / the system boost preprocessor library is ever used over the Firebird-internal copy. It also looks like it's also just used in an other build tool and nothing of the Firebird DB itself depends on it. Then there is the movement of the install_name_tool / otool patching on MacOS from the patch into the ExternalProject to further shrink the patches, as the build doesn't depend on it. This also introduces a different debug build mode for the gcc-/g++-wrapper: MSVC_USE_INDIVIDUAL_PDBS. It uses -Fd to write a separate PDB per output file instead of using -FS to use sync writes to a single PDB, which might work around the PDB access failures seen by Jenkins for linking executables. In theory it's also faster and should work with all the other wrapper users, but I don't want to open that can of additional build errors (yet), for eventually marginal gains. Change-Id: I8d4c5d2f17def9e840a67ef1004787e8baaffa83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105902 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-11-18Make firebird build for macOS on arm64Tor Lillqvist
No idea whether it works. Change-Id: I008cf9fab56bedb2e1f33ad6a99c9cd95d7483a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106024 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-11-17firebird: fix Thread handle type on WindowsJan-Marek Glogowski
MSVC compiler complains about 'warning C4312: "reinterpret_cast": conversion from "unsigned long" to "HANDLE" of greater size'. Seems like an real error, if real_handle is too small to hold the full "HANDLE" value, returned by _beginthreadex. Upstream strangely just fixed in master, not B3_0_Release branch. Change-Id: I87ad263529e119f68da976245646bf8b69efd35a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105924 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-11-16Modify the non-symlink libfbclient.dylib.3.0.0Stephan Bergmann
At least in my --enable-debug build, workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib originally contains libfbclient.dylib -> libfbclient.dylib.2 libfbclient.dylib.2 -> libfbclient.dylib.3.0.0 libfbclient.dylib.3.0.0 so if we modify libfbclient.dylib with install_name_tool, it will break the symlink and modify libfbclient.dylib but not libfbclient.dylib.3.0.0---where the latter is what gets delivered via external/firebird/ExternalPackage_firebird.mk. (This didn't cause any issues, though, because gb_LinkTarget__use_libfbembed in RepositoryExternal.mk links against the modified libfbclient.dylib in workdir, not against the delivered libfbclient.dylib.3.0.0, so e.g. Library_firebird_sdbc did already contain the correct @loader_path/libfbclient.dylib.3.0.0 reference. Also, the `install_name_tool -id` treatment of libEngine12.dylib in external/firebird/firebird-macosx.patch.1 should not technically be necessary, as nothing links against that library; but if left unmodified, it would record the build machine's /full-path-to/workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.dylib so better "clean it up". Also, the `install_name_tool -change` treatment of libEngine12.dylib in external/firebird/firebird-macosx.patch.1 is necessary because otherwise it would record a full-path dependency to /full-path-to/workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.dylib.3.0.0 which macosx-change-install-names.pl, called from MAKE_POST in external/firebird/ExternalProject_firebird.mk, would not adjust. With all those modifications in external/firebird/firebird-macosx.patch.1, the call to macosx-change-install-names.pl should effectively have nothing left to do, as these libraries do not depend on any other LO-provided libraries, but better leave it in place anyway.) Change-Id: Icf7f2ff5cb844b07be223e0b74cd6a650725777a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-21external/firebird: Remove dead conditionalsStephan Bergmann
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>
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-21external/firebird: Make comparison operator member functions constStephan Bergmann
see commit message of external/firebird/0001-Make-comparison-operator-member-functions-const.patch.1 for details Change-Id: I559e4b6ef2dbf3800ff5013dcde078d69296d2fb Reviewed-on: https://gerrit.libreoffice.org/81261 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-23Resolves: tdf#125284 config entries not substituted under Turkish localeCaolán McNamara
cause i is not the lowercase of I Change-Id: I616d642df54ce19e68d484c43250a79ecae344ee Reviewed-on: https://gerrit.libreoffice.org/78025 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-05-05Fix remaining uses of gb_SYMBOLStephan Bergmann
...after eeeec33ada5923f1f534334b22c15d6e2c6f1d35 "merge --enable-selective-debuginfo into --enable-symbols" had removed it Change-Id: I83aed6e21c4b983d8645707daa65bd85ec16ff6b Reviewed-on: https://gerrit.libreoffice.org/71798 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-02-03firebird: fix CXXFLAGSMichael Stahl
In 3.0.4, the horrible makefiles override the CXXFLAGS variable: firebird/builds/posix/prefix.linux_generic:CXXFLAGS=-std=gnu++03 Work around that by passing LO's customised CXXFLAGS as a command-line parameter to make, which in turn overrides the definition in the makefile. Other platforms, in particular Darwin, apparently extend CXXFLAGS instead of overwriting. To nobody's surprise, gnu++03 doesn't even build with clang because ICU headers use C++11 features (although strangely gcc doesn't complain). Change-Id: If3b26482a4f4bf284057e261677cd7182656154f Reviewed-on: https://gerrit.libreoffice.org/67255 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-01-30Ensure configuration that defines math_errhandling in <cmath>Stephan Bergmann
...as demanded by the C++17 standard, and required in sc/source/core/tool/math.cxx. At least when building an --arch=i386 Flatpak (where CFLAGS/CXXFLAGS are passed in containing, among others, -O2), that failed when using -std=gnu++2a (instead of -std=c++2a) due to what looks like an error in glibc (cf. <https://flathub.org/builds/#/builders/22/builds/797>). ...and fix fallout in external/firebird for Linux x86 32-bit build: While GCC defines both __i386 and __i386__ (both as 1) regardless of -std=gnu++* vs. -std=c++*, it defines i386 (as 1) only for -std=gnu++*. But various places in the external/firebird sources check for i386 (among them src/common/common.h, which fails with #error Define FB_CPU for your platform if i386 is not defined). Change-Id: I7dce1961c79aeaccc82b1e2bdc350e02730d46af Reviewed-on: https://gerrit.libreoffice.org/67105 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-15Allow all _MSC_VER up to (excluding) 2000 (Firebird)Mike Kaganski
(see https://blogs.msdn.microsoft.com/vcblog/2016/10/05/visual-c-compiler-version/) Change-Id: I69133a3742f72c20daa0ad94e093e4fffbd5d8c2 Reviewed-on: https://gerrit.libreoffice.org/59097 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-06-03firebird: adapt asan.patch to GCC, which lacks __has_featureMichael Stahl
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>
2018-04-17We don't build for i386 on macOS anywayTor Lillqvist
No no need to patch the Firebird build settings for i386. Change-Id: Ic187ff462325511a9a498e312f54350be7542366 Reviewed-on: https://gerrit.libreoffice.org/53054 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-04-17external/firebird: Better workaround for Clang alignment expectationsStephan Bergmann
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>
2018-04-16Pass gb_SYMBOL into external/firebirdStephan Bergmann
Change-Id: I91e68dfe770aaa906abac107c3e56bc5e4782512 Reviewed-on: https://gerrit.libreoffice.org/52937 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-04-13external/firebird: Even more LIBO_TUNNEL_LIBRARY_PATHStephan Bergmann
...as needed by some builders, apparently. Change-Id: I94f3059121d21d55fc7f87d5554bf192f6858e06
2018-04-13external/firebird: Even more LIBO_TUNNEL_LIBRARY_PATHStephan Bergmann
...as needed by some builders, apparently. Change-Id: I0b7c063ef2c712a6b32aa107ab733a3723b38f99
2018-04-12external/firebird: More LIBO_TUNNEL_LIBRARY_PATHStephan Bergmann
...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>
2018-04-12external/firebird: Support Clang ASanStephan Bergmann
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>
2018-04-11external/firebird: Avoid -fsanitize=nonnull-attributeStephan Bergmann
...that hits at least during the build of firebird with also ASan enabled (support for which will be committed shortly): > [...]/workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql -q -i [...]/workdir/UnpackedTarball/firebird/src/dbs/metadata.sql > workdir/UnpackedTarball/firebird/src/jrd/btr.cpp:5394:19: runtime error: null pointer passed as argument 2, which is declared to never be null > /usr/include/string.h:43:28: note: nonnull attribute specified here > #0 in insert_node(Jrd::thread_db*, Jrd::win*, Jrd::index_insertion*, Jrd::temporary_key*, RecordNumber*, unsigned int*, unsigned int*) at workdir/UnpackedTarball/firebird/src/jrd/btr.cpp:5394:2 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1ae2914) > #1 in add_node(Jrd::thread_db*, Jrd::win*, Jrd::index_insertion*, Jrd::temporary_key*, RecordNumber*, unsigned int*, unsigned int*) at workdir/UnpackedTarball/firebird/src/jrd/btr.cpp:2279:24 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1ac5a92) > #2 in BTR_insert(Jrd::thread_db*, Jrd::win*, Jrd::index_insertion*) at workdir/UnpackedTarball/firebird/src/jrd/btr.cpp:1008:21 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1ac29b5) > #3 in insert_key(Jrd::thread_db*, Jrd::jrd_rel*, Jrd::Record*, Jrd::jrd_tra*, Jrd::win*, Jrd::index_insertion*, Jrd::IndexErrorContext&) at workdir/UnpackedTarball/firebird/src/jrd/idx.cpp:1475:2 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1c62e01) > #4 in IDX_store(Jrd::thread_db*, Jrd::record_param*, Jrd::jrd_tra*) at workdir/UnpackedTarball/firebird/src/jrd/idx.cpp:1018:22 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1c661a2) > #5 in Jrd::StoreNode::store(Jrd::thread_db*, Jrd::jrd_req*, Jrd::StmtNode::WhichTrigger) const at workdir/UnpackedTarball/firebird/src/dsql/StmtNodes.cpp:7005:5 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x21c0c96) > #6 in Jrd::StoreNode::execute(Jrd::thread_db*, Jrd::jrd_req*, Jrd::StmtNode::ExeState*) const at workdir/UnpackedTarball/firebird/src/dsql/StmtNodes.cpp:6942:13 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x21bf955) > #7 in EXE_looper(Jrd::thread_db*, Jrd::jrd_req*, Jrd::StmtNode const*) at workdir/UnpackedTarball/firebird/src/jrd/exe.cpp:1292:17 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x157f798) > #8 in looper_seh(Jrd::thread_db*, Jrd::jrd_req*, Jrd::StmtNode const*) at workdir/UnpackedTarball/firebird/src/jrd/exe.cpp:1426:2 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x15834fc) > #9 in execute_looper(Jrd::thread_db*, Jrd::jrd_req*, Jrd::jrd_tra*, Jrd::StmtNode const*, Jrd::jrd_req::req_s) at workdir/UnpackedTarball/firebird/src/jrd/exe.cpp:1023:2 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x15740c3) > #10 in EXE_send(Jrd::thread_db*, Jrd::jrd_req*, unsigned short, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/jrd/exe.cpp:833:2 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1579392) > #11 in add_index_set(Jrd::thread_db*) at workdir/UnpackedTarball/firebird/temp/Debug/jrd/ini.cpp:2251:3 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1efb0c2) > #12 in INI_format(char const*, char const*) at workdir/UnpackedTarball/firebird/temp/Debug/jrd/ini.cpp:1563:2 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1eef3bd) > #13 in Jrd::JProvider::createDatabase(Firebird::CheckStatusWrapper*, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/jrd/jrd.cpp:2691:4 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1864267) > #14 in Firebird::IProviderBaseImpl<Jrd::JProvider, Firebird::CheckStatusWrapper, Firebird::IPluginBaseImpl<Jrd::JProvider, Firebird::CheckStatusWrapper, Firebird::Inherit<Firebird::IReferenceCountedImpl<Jrd::JProvider, Firebird::CheckStatusWrapper, Firebird::Inherit<Firebird::IVersionedImpl<Jrd::JProvider, Firebird::CheckStatusWrapper, Firebird::Inherit<Firebird::IProvider> > > > > > >::cloopcreateDatabaseDispatcher(Firebird::IProvider*, Firebird::IStatus*, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/include/firebird/IdlFbInterfaces.h:9010:44 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x16eefb6) > #15 in Firebird::IAttachment* Firebird::IProvider::createDatabase<Firebird::CheckStatusWrapper>(Firebird::CheckStatusWrapper*, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/include/firebird/IdlFbInterfaces.h:2034:23 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x49cc5d) > #16 in Why::Dispatcher::attachOrCreateDatabase(Firebird::CheckStatusWrapper*, bool, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/yvalve/why.cpp:5681:15 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x44d0ad) > #17 in Why::Dispatcher::createDatabase(Firebird::CheckStatusWrapper*, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/yvalve/why.cpp:5606:9 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x44e4d4) > #18 in PREPARSE_execute(Firebird::CheckStatusWrapper*, Why::YAttachment**, unsigned short, char const*, bool*, unsigned short) at workdir/UnpackedTarball/firebird/src/yvalve/preparse.cpp:288:26 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x56e738) > #19 in Why::UtilInterface::executeCreateDatabase(Firebird::CheckStatusWrapper*, unsigned int, char const*, unsigned int, unsigned char*) at workdir/UnpackedTarball/firebird/src/yvalve/utl.cpp:587:8 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x5ee78f) > #20 in Firebird::IUtilBaseImpl<Why::UtilInterface, Firebird::CheckStatusWrapper, Firebird::IVersionedImpl<Why::UtilInterface, Firebird::CheckStatusWrapper, Firebird::Inherit<Firebird::IUtil> > >::cloopexecuteCreateDatabaseDispatcher(Firebird::IUtil*, Firebird::IStatus*, unsigned int, char const*, unsigned int, unsigned char*) at workdir/UnpackedTarball/firebird/src/include/firebird/IdlFbInterfaces.h:12375:44 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x60ed0b) > #21 in Firebird::IAttachment* Firebird::IUtil::executeCreateDatabase<Firebird::CheckStatusWrapper>(Firebird::CheckStatusWrapper*, unsigned int, char const*, unsigned int, unsigned char*) at workdir/UnpackedTarball/firebird/src/include/firebird/IdlFbInterfaces.h:3504:23 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x603d95) > #22 in create_db(char const*, char*) at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:5314:38 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x5aee53) > #23 in frontend(char const*) at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:6152:10 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x59b585) > #24 in get_statement(char*, unsigned long, char const*) at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:7019:9 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x596084) > #25 in do_isql() at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:5481:9 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x57ba26) > #26 in ISQL_main(int, char**) at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:1693:3 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x575ecc) > #27 in main at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:1599:9 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x575149) > #28 in __libc_start_main at /usr/src/debug/glibc-2.26-146-gd300041c53/csu/../csu/libc-start.c:308 (/lib64/libc.so.6 +0x20f29) > #29 in _start at <null> (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x423219) Change-Id: Iebff0484a792b711769f46c4823f806e9f9b2935 Reviewed-on: https://gerrit.libreoffice.org/52704 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-04-09external/firebird: ICU_UCHAR_TYPE breaks -fsanitize=functionStephan Bergmann
...while building external/firebird, and should not be necessary in a C++ project anyway (cf. 4c404950225e07ec7ee5275657a3192a5af79a04 "ICU_UCHAR_TYPE is not needed for C++11 projects"). I started to get this failure around the time I switched the machine from Fedora 27 to Fedora 28 beta, but not sure whether the issue is related to that, nor why it only started to happen now: > workdir/UnpackedTarball/firebird/src/intl/cs_icu.cpp:67:30: runtime error: call to function ucnv_fromUChars_60 through pointer to incorrect function type 'int (*)(UConverter *, char *, int, const unsigned short *, int, UErrorCode *)' > workdir/UnpackedTarball/icu/source/common/ucnv.cpp:1720: note: ucnv_fromUChars_60 defined here > #0 in CSICU_charset_init(charset*, char const*) at workdir/UnpackedTarball/firebird/src/intl/cs_icu.cpp:67:30 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/intl/libfbintl.so +0xb5a9c) > #1 in LD_lookup_charset at workdir/UnpackedTarball/firebird/src/intl/ld.cpp:484:10 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/intl/libfbintl.so +0xb34e4) > #2 in LCICU_setup_attributes(char const*, char const*, char const*, Firebird::StringBase<Firebird::StringComparator> const&, Firebird::StringBase<Firebird::StringComparator>&) at workdir/UnpackedTarball/firebird/src/intl/lc_icu.cpp:128:8 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/intl/libfbintl.so +0xaf3e2) > #3 in LD_setup_attributes at workdir/UnpackedTarball/firebird/src/intl/ld.cpp:568:7 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/intl/libfbintl.so +0xb47ff) > #4 in Jrd::IntlManager::setupCollationAttributes(Firebird::StringBase<Firebird::StringComparator> const&, Firebird::StringBase<Firebird::StringComparator> const&, Firebird::StringBase<Firebird::StringComparator> const&, Firebird::StringBase<Firebird::StringComparator>&) at workdir/UnpackedTarball/firebird/src/jrd/IntlManager.cpp:689:16 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x16ecd8b) > #5 in setupSpecificCollationAttributes(Jrd::thread_db*, Jrd::jrd_tra*, unsigned short, char const*) at workdir/UnpackedTarball/firebird/temp/Debug/jrd/dfw.cpp:7483:7 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1918f67) > #6 in create_collation(Jrd::thread_db*, short, Jrd::DeferredWork*, Jrd::jrd_tra*) at workdir/UnpackedTarball/firebird/temp/Debug/jrd/dfw.cpp:7542:3 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1936e2e) > #7 in DFW_perform_work(Jrd::thread_db*, Jrd::jrd_tra*) at workdir/UnpackedTarball/firebird/temp/Debug/jrd/dfw.cpp:4513:11 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x1912e49) > #8 in DFW_perform_system_work(Jrd::thread_db*) at workdir/UnpackedTarball/firebird/temp/Debug/jrd/dfw.cpp:4457:2 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x191259d) > #9 in INI_format(char const*, char const*) at workdir/UnpackedTarball/firebird/temp/Debug/jrd/ini.cpp:1808:2 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x18df473) > #10 in Jrd::JProvider::createDatabase(Firebird::CheckStatusWrapper*, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/jrd/jrd.cpp:2691:4 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x172d05f) > #11 in Firebird::IProviderBaseImpl<Jrd::JProvider, Firebird::CheckStatusWrapper, Firebird::IPluginBaseImpl<Jrd::JProvider, Firebird::CheckStatusWrapper, Firebird::Inherit<Firebird::IReferenceCountedImpl<Jrd::JProvider, Firebird::CheckStatusWrapper, Firebird::Inherit<Firebird::IVersionedImpl<Jrd::JProvider, Firebird::CheckStatusWrapper, Firebird::Inherit<Firebird::IProvider> > > > > > >::cloopcreateDatabaseDispatcher(Firebird::IProvider*, Firebird::IStatus*, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/include/firebird/IdlFbInterfaces.h:9010:44 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.so +0x10d511f) > #12 in Firebird::IAttachment* Firebird::IProvider::createDatabase<Firebird::CheckStatusWrapper>(Firebird::CheckStatusWrapper*, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/include/firebird/IdlFbInterfaces.h:2034:23 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x3937f4) > #13 in Why::Dispatcher::attachOrCreateDatabase(Firebird::CheckStatusWrapper*, bool, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/yvalve/why.cpp:5681:15 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x35adb7) > #14 in Why::Dispatcher::createDatabase(Firebird::CheckStatusWrapper*, char const*, unsigned int, unsigned char const*) at workdir/UnpackedTarball/firebird/src/yvalve/why.cpp:5606:9 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x35baa4) > #15 in PREPARSE_execute(Firebird::CheckStatusWrapper*, Why::YAttachment**, unsigned short, char const*, bool*, unsigned short) at workdir/UnpackedTarball/firebird/src/yvalve/preparse.cpp:288:26 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x427888) > #16 in Why::UtilInterface::executeCreateDatabase(Firebird::CheckStatusWrapper*, unsigned int, char const*, unsigned int, unsigned char*) at workdir/UnpackedTarball/firebird/src/yvalve/utl.cpp:587:8 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x481209) > #17 in Firebird::IUtilBaseImpl<Why::UtilInterface, Firebird::CheckStatusWrapper, Firebird::IVersionedImpl<Why::UtilInterface, Firebird::CheckStatusWrapper, Firebird::Inherit<Firebird::IUtil> > >::cloopexecuteCreateDatabaseDispatcher(Firebird::IUtil*, Firebird::IStatus*, unsigned int, char const*, unsigned int, unsigned char*) at workdir/UnpackedTarball/firebird/src/include/firebird/IdlFbInterfaces.h:12375:44 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2 +0x495a09) > #18 in Firebird::IAttachment* Firebird::IUtil::executeCreateDatabase<Firebird::CheckStatusWrapper>(Firebird::CheckStatusWrapper*, unsigned int, char const*, unsigned int, unsigned char*) at workdir/UnpackedTarball/firebird/src/include/firebird/IdlFbInterfaces.h:3504:23 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x4c41df) > #19 in create_db(char const*, char*) at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:5314:38 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x48606b) > #20 in frontend(char const*) at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:6152:10 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x477e4e) > #21 in get_statement(char*, unsigned long, char const*) at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:7019:9 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x4740e6) > #22 in do_isql() at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:5481:9 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x461d48) > #23 in ISQL_main(int, char**) at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:1693:3 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x45d8cf) > #24 in main at workdir/UnpackedTarball/firebird/temp/Debug/isql/isql.cpp:1599:9 (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x45cf09) > #25 in __libc_start_main at <null> (/lib64/libc.so.6 +0x231ba) > #26 in _start at <null> (workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql +0x40bd89) Change-Id: I7b31e2e6dd745e50d02c68369c7a1e8072ae9534 Reviewed-on: https://gerrit.libreoffice.org/52622 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-21 12:02:32 +0000