Re: [porting-dev] star suite dies after setup sparc linux gcc-3.3
thanks Kevin - see results below.
On Mon, 16 Jun 2003 09:36 pm, Kevin B. Hendricks wrote:
> libsal.so.3.1.0 is a versioned library. Perhas the symlinks are missing
> libsal.so.3 -> libsal.so.3.1.0.
sun:~/no_sal_cppu_OpenOffice.org1.1/program> ls -la libsal.so*
lrwxrwxrwx 1 jim jim 11 Jun 16 20:26 libsal.so ->
libsal.so.3
lrwxrwxrwx 1 jim jim 15 Jun 16 20:26 libsal.so.3 ->
libsal.so.3.1.0
-r--r--r-- 1 jim jim 1962617 Jun 13 06:10 libsal.so.3.1.0
>
> If you run ldd on libsw644ls.so what does the list of dependent libraries
> shown.
sun:~/no_sal_cppu_OpenOffice.org1.1/program>
ldd libsw644ls.so | grep libsal.so
libsal.so.3 => ./libsal.so.3 (0x737c4000)
> Perhaps there are
> missing symbols or a shared library that coan't be found in libsal?
sun:~/no_sal_cppu_OpenOffice.org1.1/program>
nm libsal.so | grep rtl_allocateMemory
00029f64 T rtl_allocateMemory
sun:~/no_sal_cppu_OpenOffice.org1.1/program>
nm libsw644ls.so | grep rtl_allocateMemory
U rtl_allocateMemory
^^^^ is this it?
>
> Does ldd on libsw644ls.so show libsal.so.3 as being a dependent (it
> should). Have the symlinks properly been created to support the versioned
> name for sal? Does ldd show all of sal's supporting libraries being found?
sun:~/no_sal_cppu_OpenOffice.org1.1/program> ldd libsal.so.3
libdl.so.2 => /lib/libdl.so.2 (0x701d8000)
libpthread.so.0 => /lib/libpthread.so.0 (0x701ec000)
libm.so.6 => /lib/libm.so.6 (0x7024c000)
libc.so.6 => /lib/libc.so.6 (0x702d0000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x08000000)
note - the above sw was linked without -lsal, -lcppu. this was done to see how
it changes the error messages on running soffice. for now i will revert to
gcc-3.2.2 as Martin has suggested, and will later report if i see why 3.3 is
different.
> Kevin
>
> On Monday 16 June 2003 07:01, Jim Watson wrote:
> > 1.1beta2 built on sparc linux gcc-3.3 now does run setp, register
> > components and runs with drawing, spreadsheet and presentation. I got to
> > here by linking sw without -lsal but libsw644ls.so still has problems,
> > now searching for something else.
> >
> > the real point here is that sw, sd and sc were all linked with
> > --export-dynamic, so i am assuming that the linker switches are not the
> > problem, there is a problem specific to sw.
> >
> > i wonder why does setup refuse to register component libsw644ls.so,
> > but setup is happy to register the same component libsw644ls.so when it
> > was linked without -lsal ??
> >
> > On Thu, 12 Jun 2003 10:22 pm, Martin Hollmichel wrote:
> > > this looks like that rtl_uString_newFromAscii is searched within the sw
> > > library but it comes from sal in reality. iis this a result of the
> > > cahnged linker switches ?
Reply to: