oo-buildsrv2

[Stephan Bergmann]

[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.in.patch
Type: text/x-patch
Size: 4832 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120516/b4188362/attachment.bin>