Hi Kevin, Sorry for the delayed reply ...
On Mon, 2011-08-22 at 12:08 -0400, Kevin Hunter wrote: > I haven't seen a fix go by, and have seen nothing mentioned on the list > regarding building the splash part of desktop, but I'm having an issue > that appears to be solved by switching to g++ instead of gcc: Hmm - I don't really understand that I must confess. > Making: oosplash > ccache /usr/local/bin/gcc -Wl,-z,noexecstack -Wl,-z,combreloc .. > /home/kevin/devel/libreoffice/solver/350/unxlngx6/lib/libuno_sal.so: > undefined reference to > `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15' > collect2: ld returned 1 exit status > dmake: Error code 1, while making '../../unxlngx6/bin/oosplash' So - I have: /opt/icecream/bin/gcc -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs -Wl,-Bsymbolic-functions -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,--hash-style=gnu -Wl,-rpath,'$ORIGIN:$ORIGIN/../basis-link/program: $ORIGIN/../basis-link/ure-link/lib',--enable-new-dtags -Wl,-export-dynamic -Wl,-rpath-link,../../unxlngi6.pro/lib:/data/opt/libreoffice/core/solver/350/unxlngi6.pro/lib:/lib:/usr/lib -L../../unxlngi6.pro/lib -L../lib -L/data/opt/libreoffice/core/solenv/unxlngi6/lib -L/data/opt/libreoffice/core/solver/350/unxlngi6.pro/lib -L/data/opt/libreoffice/core/solenv/unxlngi6/lib ../../unxlngi6.pro/obj/splashx.o ./../unxlngi6.pro/obj/start.o ../../unxlngi6.pro/obj/args.o ./../unxlngi6.pro/obj/pagein.o ../../unxlngi6.pro/obj/file_image_unx.o -lpthread -Wl,--as-needed -lXext -lX11 -Wl,--no-as-needed -luno_sal -lpng14 -lXinerama -o ../../unxlngi6.pro/bin/oosplash Which works fine here at least. And I have no list_node_base related symbol at all exported from libuno_sal.so - odd. > By executing that line manually and switching to /usr/local/bin/g++ the > compile is successful. And that point I can restart the build and LO > finishes with a successful build. Which is indeed odd. > It looks like the source of those files is C, but the libuno_sal is a > .cpp file. I'm not clear on the linking rules bewteen the C and CPP, > but given that no one else is having this issue, is there something else > that I'm missing? So - libuno_sal is a C++ library, certainly - but surely we should be able to link it without any magic. I wonder what changed there ? libuno_sal.so - clearly does have a number of C++ exports it requires (objdump -T shows): 00000000 DF *UND* 00000000 GLIBCXX_3.4 _ZSt20__throw_length_errorPKc But then again, it links to libstdc++ $ ldd ../sal/unxlngi6.pro/lib/libuno_sal.so linux-gate.so.1 => (0xffffe000) libdl.so.2 => /lib/libdl.so.2 (0xb7762000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7747000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7658000) libm.so.6 => /lib/libm.so.6 (0xb762e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb760f000) libc.so.6 => /lib/libc.so.6 (0xb74a2000) /lib/ld-linux.so.2 (0xb77db000) $ objdump -T /usr/lib/libstdc++.so.6 | grep _ZSt20__throw_length_errorPKc 00055890 g DF .text 000000d5 GLIBCXX_3.4 _ZSt20__throw_length_errorPKc At least for me ... Can you do some more investigation of which symbol is missing from where ? of course, failing that we can do some horror of a rename in there, or perhaps poking at removing things like: desktop/unx/source/makefile.mk: APP1CODETYPE = C might help - but ... ideally we want as little junk in the splash app as humanly possible; it'd be most ideal not to link sal at all IMHO but ... ;-) its more work to avoid it. Thanks, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice