[Libreoffice] gcc/g++ compilation issue in desktop/splash
michael.meeks at novell.com
Wed Aug 24 10:06:44 PDT 2011
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
> undefined reference to
> 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,-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
-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)
$ 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:
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.
michael.meeks at novell.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice