Age | Commit message (Collapse) | Author |
|
Following up on 7a4cc197910546d6fb3469806c406bf358ba0168 "Also on Linux do not
export symbols from static orcus libraries" that turned out to not be enough to
prevent ASan ODR violation reports after
f0aa1a78fb209310e8baef53c02f365fca518d11 "For Clang -fsanitize=vptr use
-fvisibility-ms-compat, not -fvisibility=hidden." Given that liborcus is only
ever linked in as a static archive, it is hopefully OK (intended, even?) to not
export any of its symbols.
Change-Id: Ib8eb084def1725374747a389065bf8186218786e
|
|
Change-Id: Icf872e269c7e427ba1287ccd0082974c9426449e
|
|
Change-Id: I39e65a9ee3ede5217d9d6d8499297e449af798fe
Reviewed-on: https://gerrit.libreoffice.org/14559
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Id367dee6c4fe55fe039ebf28603c883014194832
|
|
Change-Id: Ieb13095abb399662e449fad5a056999343165025
|
|
Change-Id: I38b2ecf86d4334d0179362079a216df4301bf184
|
|
...like 2fdf78109e815a64169fdab1a8175b63ef9c64d4 "Pass MAKE into
external/poppler's configure"
Change-Id: I4e2f1a13d120a7398fa81884710c589bb905714d
|
|
Change-Id: I8f2176500bf620cd5e4cdf434e6122b6163b3e0f
|
|
...otherwise e.g. running CppunitTest_sc_filters_test under -fsanitize=address
complains about ODR violation of 'vtable for orcus::csv::parse_error' exported
from both libsclo.so and libscqahelper.so.
A problem could potentially arise with exceptions thrown from static orcus code
linked into library and intended to be caught in another, but hopefully all such
exceptions are intended to be caught already locally anyway.
Change-Id: Iff5c73d7a2324b457c2e86656c11b18f7ba210f6
|
|
Change-Id: I9f60fd317f3a2995a182d51d06059bd994cf837c
|
|
The libgltf configure.ac script changes the autotools user variables
CFLAGS and CXXFLAGS, which is not allowed and can overwrite user
settings (which it does for the -D_GLIBCXX_DEBUG flag).
So this moves the special compile settings to seperate variables and
passes them to AM_CXXFLAGS and AM_CPPFLAGS, so the library actually
gets compiled with libstdc++ debug objects.
Change-Id: I00989f5fb629a6aac43ee5a2eb287b0491a3b86d
|
|
They have been applied upstream and are part of the new release.
Change-Id: I928b29e74abe2415bdf75de32cbaa7ac279a2889
|
|
Change-Id: I6619e70f3f7c8ba4d17be4ca434057948be3d79f
|
|
Conflicts:
external/boost/StaticLibrary_boost_system.mk
Change-Id: Ie4af26c87a100b67baeedbaa7fb1ac428845f92b
|
|
Change-Id: I0cc43cef91e3fcd82a3558a16ab0afbd4d56b141
|
|
liborcus was not building for me with -flto in CFLAGS, I would have to
fix ar somehow.
-flto in LDFLAGS is just to fix the build if the external library does use
another library built by us with -flto: does happen for liborcus and python3.
It's not like we would use -flto for external libraries consistently anyway,
the only exception is icu: no idea why we build with -flto there.
Change-Id: Ia54d619674b8999ce5e4b920ba77b1587c9cf48d
|
|
Change-Id: Ie24054a9c0538187e1b234101dd41f30306ec2ae
|
|
Change-Id: I2fce6545d7f279e0e2d6f3ff53eee1ab82314135
|
|
Change-Id: I7530cb9d0797df5fc86695b0379cc44c159d2ab5
|
|
Change-Id: I82fff6ab89acece0e46c92bfca2c7faf967639b8
|
|
... why didn't GCC 4.1 have #pragma diagnostic push?
Change-Id: Iedb33d6451e46dc12e137bcd4dccd592c7771c23
|
|
... it breaks dependency generation.
Change-Id: Ib6e1dac1210020d3a6eb1748f1266e69582f199e
|
|
Change-Id: Ibdf8c9fc9d7d2639ebd440ff2d833ab37ae76d98
Reviewed-on: https://gerrit.libreoffice.org/6334
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|