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

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.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot