| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Idbd4ad7ad89dc727e2f0cf851c4c62f05d5b2a0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166328
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
...since 2193650b3373ee1889961cfb72d1fe97f73e2c23 "external/coinmp: Update to
CoinMP 1.8.4", as reported by <https://ci.libreoffice.org/job/lo_ubsan/2805/>,
> ==25531==ERROR: AddressSanitizer: odr-violation (0x7f3df9756e40):
> [1] size=4 'CbcOrClpEnvironmentIndex' /home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/UnpackedTarball/coinmp/Clp/src/CbcOrClpParam.cpp:1236:5
> [2] size=4 'CbcOrClpEnvironmentIndex' CbcOrClpParam.cpp:1236:5
> These globals were registered at these points:
> [1]:
> #0 0x43e508 in __asan_register_globals.part.13 /home/tdf/lode/packages/llvm-llvmorg-12.0.1.src/compiler-rt/lib/asan/asan_globals.cpp:360
> #1 0x7f3df9252a6b in asan.module_ctor (/instdir/program/libCbcSolver.so.3+0x21fa6b)
> LLVMSymbolizer: error reading file: No such file or directory
> #2 0x7ffda20d8279 ([stack]+0x32279)
>
> [2]:
> #0 0x43e508 in __asan_register_globals.part.13 /home/tdf/lode/packages/llvm-llvmorg-12.0.1.src/compiler-rt/lib/asan/asan_globals.cpp:360
> #1 0x7f3df4973a4b in asan.module_ctor (/instdir/program/libClpSolver.so.1+0x127a4b)
> #2 0x7ffda20d8279 ([stack]+0x32279)
and similarly for CbcOrClpRead_mode and CbcOrClpReadCommand.
There's code using those three extern variables in both libCbcSolver.so.3 and
libClpSolver.so.1, and some of it is duplicated (in
workdir/UnpackedTarball/coinmp/Clp/src/CbcOrClpParam.cpp, which is also included
from workdir/UnpackedTarball/coinmp/Cbc/src/CbcCbcParam.cpp). Those libraries
do not appear to make any use of symbol visibility hiding, and it is completely
unclear to me how all that code is actually meant to work. But it also smells
like all that code is only used within standalone programs (see main in
workdir/UnpackedTarball/coinmp/Cbc/src/CoinSolve.cpp and
workdir/UnpackedTarball/coinmp/Clp/src/ClpMain.cpp). So lets try to get away
with properly sharing those three extern variables across those two libraries.
Except on Windows, where linking the one library wouldn't find the extern
variables from the other library (and I'm not sure whether that's a general
issue on Windows, or is due to how 2193650b3373ee1889961cfb72d1fe97f73e2c23
modified external/coinmp/windows.build.patch.1).
(This also appears to be fixed on recent upstream;
<https://github.com/coin-or/Cbc> no longer mentions any of those three extern
variables. Maybe a new tarball will eventually appear at
<http://www.coin-or.org/download/source/CoinMP/> that includes a proper fix of
these ODR violations.)
Change-Id: I953c7dc31f8e35315c59dc2bedd3fdf780579638
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...originally started mostly to simplify a then-upcoming change to address
std::bind2nd gone from libc++ for C++17 (which turned out to already be
partially addressed in this new CoinMP revision). But that has since been
addressed with b97e8b9d13ef0f57f7cf0badbefcb038a8bbd137 "external/coinmp: Adapt
to std::bind2nd gone from C++17" on top of the old CoinMP 1.7.6, because
updating to 1.8.4 turned out to run into issues on Windows, see the email thread
starting at
<https://lists.freedesktop.org/archives/libreoffice/2022-September/089383.html>
"Maintaining building external/coinmp on Windows".
* <https://dev-www.libreoffice.org/src/CoinMP-1.8.4.tgz> is a copy of
<https://www.coin-or.org/download/source/CoinMP/CoinMP-1.8.4.tgz>.
* Various of our patches are meanwhile addressed upstream, partially or in
whole.
* The upstream configure scripts deteriorated and caused one of my Linux build's
CC=/absolute/path/to/some/clang to be mistaken for MSVC which caused them to
force LD=link, which in turn caused them to only build archives and not the
shared libraries that we expect. external/coinmp/clang-with-path.patch
addresses that.
* There's apparently a new ClpSolver library now that also needs to be
installed. Otherwise at least CppunitTest_sccomp_swarmsolvertest failed due
to
> warn:sal.osl:1950612:1950612:sal/osl/unx/module.cxx:152: dlopen(instdir/program/libsolverlo.so, 257): libClpSolver.so.1: cannot open shared object file: No such file or directory
* Plus modifications to external/coinmp/windows.build.patch.1 thankfully done by
Taichi Haradaguchi <20001722@ymail.ne.jp> to make this actually compile on
Windows (cf. the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2022-September/089383.html>
"Maintaining building external/coinmp on Windows")
Change-Id: I498c9513fa0d96d8ae2b9ba4c09dd792340db730
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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++. (Recent
versions of GCC similarly default to C++17, but libstdc++ by default still
provides bind2nd even for C++17.) Alternatively, we could define
_LIBCPP_ENABLE_CXX17_REMOVED_BINDERS to work around this. But as these appear
to be the only leftover occurrence of bind2nd across all of the code base, and
all but one of them have already been addressed upstream, lets address it for
good with this little patch. (Where the last remaining occurrence not yet
addressed upstream is fixed in the same way as the other upstream fixes, using a
loop rather than e.g. a lambda that would force us to start to pass
CXXFLAGS_CXX11 into ExternalProejct_coinmp.)
Change-Id: Iddcdddd22ea4c6d537b64bf2cf0b887d11da162f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139931
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
> ClpSimplex.cpp:6038:2: error: use of a '#elifdef' directive is a C++2b extension [-Werror,-Wc++2b-extensions]
> #elifdef COIN_HAS_MUMPS
> ^
seen with Clang 15 trunk since
<https://github.com/llvm/llvm-project/commit/a1545f51a9ef299ca6c6716bd80b862f360453ab>
"Warn if using `elifdef` & `elifndef` in not C2x & C++2b mode" (and which is
turned into an error because External_coinmp builds with --pedantic-errors)
Change-Id: I1db213aec91bc17c720fd58270eab452b2e4e0f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134478
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
This allows to define the mapping once, and avoid modification in
multiple places each time a new VS version support is added
Change-Id: I93de4c9d78c3f67a0a2e157007e9d13b6f557937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This patch changes the configure.ac, so that LibreOffice compiles
with the latest VS 2022 preview.
The option --with-visual-studio=2022 should be added to the
autogen.input, in order to use VS 2022 preview.
Change-Id: Ia1d9bbeabbbd44ffe82af3624151b69d36c0a45c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122133
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|