[I'm including the ML in the loop. The context is Fridrich's
RHEL/CentOS 4.9 machine that, AFAIU, is used to do "official"
(www.libreoffice.org/download) release builds. It used to do so with a
custom-built GCC version, and we would like to switch to the GCC 4.1.2
that is available on RHEL/CentOS 4.9 by default. One benefit would be
that the LO builds on that machine (and the installation sets resulting
from them) would no longer need to include libstdc++.so.6 from the
custom-built GCC. However, LO's configure.in detecting the RHEL/CentOS
4.9 GCC 4.1.2 as not visibility-hidden--safe is worrying---it caused at
least on subsequentcheck failure, and who knows what else... Therefore
the attempt to build with the given GCC 4.1.2 but -fvisiblity=hidden
enabled nonetheless.]
On 05/15/2012 06:38 PM, Stephan Bergmann wrote:
Quick update before I go for the evening:
* Commented out the two "if STL headers are visibility safe (GCC bug
22482)" and "if gcc has a visibility bug with class-level attributes
(GCC bug 26905)" in configure.in, as they would each cause detection of
HAVE_GCC_VISIBILITY_FEATURE= instead of HAVE_GCC_VISIBILITY_FEATURE=TRUE.
* Result is that HAVE_GCC_VISIBILITY_FEATURE=TRUE and
HAVE_GCC_VISIBILITY_BROKEN=TRUE (where the latter suppresses
-fvisiblity-inlines-hidden).
* "make check" works (as long as I --disable-linkoo; otherwise,
strangely "make check" crashes soffice.bin when making
/home/lo/master/workdir/unxlngx6.pro/CppunitTest/smoketest.test, while
"cd smoketest && make
/home/lo/master/workdir/unxlngx6.pro/CppunitTest/smoketest.test" would
not exhibit that problem, even though the environments in which soffice
is called in each case are nearly identical -- oh my, linkoo...).
* At least for the first of the two commented-out configure.in checks,
Caolán's newly added bug links in configure.in suggest that failing the
test would lead to runtime rather than build time errors (which would be
bad for us, as a successful build would not imply we built something
useful). However, the test case (reclaim_block_segv.tar.gz) Caolán
originally attached to
<https://bugzilla.redhat.com/show_bug.cgi?id=162935> "ooimpress-creating
presentation using wizard crashes in M_reclaim_block" does not fail on
this machine (replacing g++ with g++4 in the test's script). This needs
further investigation...
The GCC 4.1.2 (gcc4, g++4) on that machine is in an odd shape. (The
default GCC on that machine is GCC 3.4.6.) rpm -qi indicates it is a
"Preview of GCC version 4.1." It does not bring along its own
include/c++/4.1.2 headers, but re-uses the GCC 3.4.6 headers at
/usr/include/c++/3.4.6. (Also, /usr/lib64/libstdc++.so.6 is from GCC
3.4.6, libstdc++.so.6.0.3.; it lacks the additional symbols of
libstdc++.so.6.0.8 corresponding to GCC 4.1.2, see
<http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html>, but maybe
that's harmless as long as GCC 4.1.2 uses the GCC 3.4.6 headers anyway.
Interestingly, /lib64/libgcc_s.so.1 is even newer than GCC 4.1.2;
"readelf -V" reveals that it is at least at GCC_4.2.0 level; maybe
RHEL/CentOS routinely include more recent versions of this
backwards-compatible lib than would correspond to the included GCC.)
Re-using the GCC 3.4.6 headers explains why the "if STL headers are
visibility safe (GCC bug 22482)" configure.in check fails. It checks
for "#pragma GCC visibility push" in the preprocessed output of
"#include <string>", and the GCC 3.4.6 headers do not include those
pragmas at all. (A stock GCC 4.1.2 built locally on a Fedora 16
machine, using its own include/c++/4.1.2 headers, would pass the test.)
It is unclear to me whether the underlying runtime issue
(<https://bugzilla.redhat.com/show_bug.cgi?id=162935>) would be
irrelevant due to the fact of using the GCC 3.4.6 headers (whose
ext/mt_allocator.h does not have any _S_get_pool, cf.
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22482#c3>), or whether it
could strike nonetheless, potentially in a different form in a different
place. (However, as I already wrote, the reclaim_block_segv.tar.gz test
case does *not* fail.)
That the "if gcc has a visibility bug with class-level attributes (GCC
bug 26905)" configure.in check fails is apparently due to this indeed
being a genuine bug in GCC 4.1.2. (My stock GCC 4.1.2 built locally on
a Fedora 16 machine fails it, too.) However, it might be OK to disable
the check (and not make it switch off HAVE_GCC_VISIBILITY_FEATURE) in
the given scenario: First, my understanding is that the bug is coupled
to the use of "#pragma GCC visibility," but due to the use of the GCC
3.4.6 headers, no such pragmas are encountered in our compilation units
(the LO code itself appears to not include such pragmas at all).
Second, my understanding is that the bug would lead to build time
(liner) errors, rather than runtime errors, so a successful build would
imply that the bug does not affect this scenario.
So, how to proceed? One plan might be to set the machine up for
libreoffice-3-5-4 tinderbox builds and encourage people to test them.
That would hopefully unearth potential runtime problems related to the
failing "if STL headers are visibility safe (GCC bug 22482)"
configure.in check.
Relevant patches are my hack to disable the two configure.in checks
(attached for reference) and
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=eda52d5e73d8918f354036cf7db3acfab43b36d7>
"FilterConfigCache not used outside svtools" to work around one problem
with R_X86_64_PC32 a la
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664> "libstdc++ headers
should have pop/push of the visibility around the declarations."
Stephan
diff --git a/configure.in b/configure.in
index b1640ea..276b0bd 100644
--- a/configure.in
+++ b/configure.in
@@ -4708,17 +4708,17 @@ if test \( "$_os" != "WINNT" -o "$WITH_MINGW" = "yes" \); then
CPPFLAGS="-isysroot $MACOSX_SDK_PATH $CPPFLAGS"
fi
- if test "$HAVE_GCC_VISIBILITY_FEATURE" = "TRUE"; then
- dnl gcc#19664, gcc#22482, rhbz#162935
- AC_MSG_CHECKING([if STL headers are visibility safe (GCC bug 22482)])
- AC_EGREP_HEADER(visibility push, string, stlvisok=yes, stlvisok=no)
- AC_MSG_RESULT([$stlvisok])
- if test "$stlvisok" = "no"; then
- AC_MSG_WARN([Your gcc STL headers are not visibility safe. Disabling visibility])
- echo "Your gcc STL headers are not visibility safe. Disabling visibility" >> warn
- unset HAVE_GCC_VISIBILITY_FEATURE
- fi
- fi
+dnl SB if test "$HAVE_GCC_VISIBILITY_FEATURE" = "TRUE"; then
+dnl SB dnl gcc#19664, gcc#22482, rhbz#162935
+dnl SB AC_MSG_CHECKING([if STL headers are visibility safe (GCC bug 22482)])
+dnl SB AC_EGREP_HEADER(visibility push, string, stlvisok=yes, stlvisok=no)
+dnl SB AC_MSG_RESULT([$stlvisok])
+dnl SB if test "$stlvisok" = "no"; then
+dnl SB AC_MSG_WARN([Your gcc STL headers are not visibility safe. Disabling visibility])
+dnl SB echo "Your gcc STL headers are not visibility safe. Disabling visibility" >> warn
+dnl SB unset HAVE_GCC_VISIBILITY_FEATURE
+dnl SB fi
+dnl SB fi
if test "$HAVE_GCC_VISIBILITY_FEATURE" = "TRUE"; then
sharedlink_ldflags_save=$LDFLAGS
@@ -4779,46 +4779,46 @@ _ACEOF
fi
fi
- if test "$HAVE_GCC_VISIBILITY_FEATURE" = "TRUE"; then
- AC_MSG_CHECKING([if gcc has a visibility bug with class-level attributes (GCC bug 26905)])
- cat >visibility.cxx <<_ACEOF
-#pragma GCC visibility push(hidden)
-struct __attribute__ ((visibility ("default"))) TestStruct {
- static void Init();
-};
-__attribute__ ((visibility ("default"))) void TestFunc() {
- TestStruct::Init();
-}
-_ACEOF
- if ! $CXX $CXXFLAGS $CPPFLAGS -fpic -S visibility.cxx 2>/dev/null > /dev/null; then
- gccvisbroken=yes
- else
- case "$host_cpu" in
- i?86|x86_64)
- if test "$_os" = "Darwin"; then
- gccvisbroken=no
- else
- if $EGREP -q '@PLT|@GOT' visibility.s; then
- gccvisbroken=no
- else
- gccvisbroken=yes
- fi
- fi
- ;;
- *)
- gccvisbroken=no
- ;;
- esac
- fi
- rm -f visibility.s visibility.cxx
-
- AC_MSG_RESULT([$gccvisbroken])
- if test "$gccvisbroken" = "yes"; then
- AC_MSG_WARN([Your gcc is not -fvisibility=hidden safe. Disabling visibility])
- echo "Your gcc is not -fvisibility=hidden safe. Disabling visibility" >> warn
- unset HAVE_GCC_VISIBILITY_FEATURE
- fi
- fi
+dnl SB if test "$HAVE_GCC_VISIBILITY_FEATURE" = "TRUE"; then
+dnl SB AC_MSG_CHECKING([if gcc has a visibility bug with class-level attributes (GCC bug 26905)])
+dnl SB cat >visibility.cxx <<_ACEOF
+dnl SB#pragma GCC visibility push(hidden)
+dnl SBstruct __attribute__ ((visibility ("default"))) TestStruct {
+dnl SB static void Init();
+dnl SB};
+dnl SB__attribute__ ((visibility ("default"))) void TestFunc() {
+dnl SB TestStruct::Init();
+dnl SB}
+dnl SB_ACEOF
+dnl SB if ! $CXX $CXXFLAGS $CPPFLAGS -fpic -S visibility.cxx 2>/dev/null > /dev/null; then
+dnl SB gccvisbroken=yes
+dnl SB else
+dnl SB case "$host_cpu" in
+dnl SB i?86|x86_64)
+dnl SB if test "$_os" = "Darwin"; then
+dnl SB gccvisbroken=no
+dnl SB else
+dnl SB if $EGREP -q '@PLT|@GOT' visibility.s; then
+dnl SB gccvisbroken=no
+dnl SB else
+dnl SB gccvisbroken=yes
+dnl SB fi
+dnl SB fi
+dnl SB ;;
+dnl SB *)
+dnl SB gccvisbroken=no
+dnl SB ;;
+dnl SB esac
+dnl SB fi
+dnl SB rm -f visibility.s visibility.cxx
+dnl SB
+dnl SB AC_MSG_RESULT([$gccvisbroken])
+dnl SB if test "$gccvisbroken" = "yes"; then
+dnl SB AC_MSG_WARN([Your gcc is not -fvisibility=hidden safe. Disabling visibility])
+dnl SB echo "Your gcc is not -fvisibility=hidden safe. Disabling visibility" >> warn
+dnl SB unset HAVE_GCC_VISIBILITY_FEATURE
+dnl SB fi
+dnl SB fi
CPPFLAGS="$save_CPPFLAGS"
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
