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@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.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
