[Libreoffice] gcc/g++ compilation issue in desktop/splash

[Caolán McNamara]

On Sun, 2011-09-04 at 15:15 -0400, Kevin Hunter wrote:
> I went ahead and did that with no love.  For reference:
> 
> $ ldd sal/unxlngx6/lib/libuno_sal.so | grep stdc
> 	libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00007f122c7cb000)

Sure sure, but when you actually end up with an install set you get a
copy of libstdc++.so.6 placed beside libuno_sal.so where the rpath
$ORIGIN stuff picks up the copy. And/or during the build LD_LIBRARY_PATH
is used to change the link path, so running ldd like above doesn't give
the same results as what would happen when you run something using
libuno_sal.so

e.g. 

[caolan at Nom core]$ ldd install/ure/lib/libuno_sal.so.3 
	libstdc++.so.6 => /home/caolan/LibreOffice/core/install/ure/lib/libstdc
++.so.6 (0x00007fc9fa177000)
	libgcc_s.so.1
=> /home/caolan/LibreOffice/core/install/ure/lib/libgcc_s.so.1 

i.e. my copy of libstdc++.so.6 is the one that will get used when I run
the final binaries. That's why I'm plinking around the issue of the
libstdc++.so.6 which gets copied/created by the external module to see
if the libstdc++.so.6 that's in there is the right one. 

You could play around with LD_DEBUG=man-page-options and see if that
gives anything useful.

> Have others had any issues compiling LO with GCC 4.6?  It's frustrating 
> and telling that I'm the only one noticing it.

Nope, I build with it all the time. However my gcc 4.6 and stdc++ are
the system ones, and not in /usr/local/somewhere

C.