Re: Building LO 4.0.4.2 on illumos based OS

On 08/07/13 13:54, Gabriele Bulfon wrote:
> > hmm... so vcl is supposed to be linked against NSS/NSPR libraries but
> > somehow that doesn't work for you....
> >
> > what is really weird is that it fails on linking the executable, it
> > should really fail when linking vcl library already.
> >
> > can you check that the link command lines use -Wl,-z,defs ?
> > apparently not, try to copy the relevant lines from
> > gbuild/platform/linux.mk to solaris.mk.
> >
> > the other problem is most likely that the libraries from the "nss"
> > module somehow have hidden visibility (i assume you are not using
> > --with-system-nss?)... if things work PR_Now should be exported like this:
> >
> > > nm --defined-only -D -g solver/*/lib/libnspr4.so | grep PR_Now
> > 0000000000039123 T PR_Now
> >
> > you'll have to dig into the external build system there to figure out
> > why it doesn't work, the files are in workdir/*/UnpackedTarball/nss (or
> > if your distro has NSS packages try using --with-system-nss).
>
> Several things appear strange to me, so here are some considerations:
> 1 - Yes, I use system libs for nspr/nss, built by my distro userland
> 2 - Doing ldd on libvcllo.so shows a lot of lib dependencies, but no
> mention about nspr nor nss libs

that is the problem.

> 3 - Doing your nm on my system libnspr4.so correctly reveals the output
> you said
> 4 - The nspr/nss libs are not under /usr/lib nor /lib in my system,
> they're all under /usr/lib/mps
>
> I tried running gmake under desktop as you requested (had to add the
> LD_ALTEXEC to force sun ld to run gnu ld instead):
>
> sonicle@vbxstreamdev:/sources/userlands/xstream-userland-gate/components/libreoffice/build/i86/desktop$
> gmake LD_ALTEXEC=/usr/gnu/bin/ld
> [build LNK] Executable/unopkg.bin
> S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1
> && O=$S/solver/unxsogi.pro && W=$S/workdir/unxsogi.pro && mkdir -p
> $W/LinkTarget/Executable/ && /usr/gcc/4.4/bin/gcc -Wl,-z,origin
> '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib
> -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib
> -L/usr/gcc/4.4/lib -L/usr/local/bin -L/usr/dt/lib -L/usr/openwin/lib
> -Wl,-O1 $W/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o
> -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket
> -lcomphelper -luno_sal -ltllo -lunopkgapp -o
> $W/LinkTarget/Executable/unopkg.bin

ok no -z,defs in there, guess that means that when linking libraries it
will not be detected when symbols are missing, which causes link
failures later in the build when the broken libraries are used.

> Analyzing better, I've seen my userland component Makefile for
> libreoffice, contains specific env:
>
> CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps
> CONFIGURE_ENV += NSS_LIBS="-L/usr/lib/mps -R/usr/lib/mps"

usually libs should contain not just search paths but also the libraries
to be linked, e.g. in config_host.mk with a system nss i get:

  export NSS_LIBS=$(gb_SPACE)-lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4
-lplc4 -lnspr4 -lpthread -ldl

also i guess only Sun ld knows -R, the GNU ld equivalent is -Wl,-rpath,

> CONFIGURE_ENV += NPAPI_HEADERS_LIBS="-L/usr/lib"
> CONFIGURE_ENV += NPAPI_HEADERS_CFLAGS="-I/usr/include/npapi"
>
> These are passed on at configure time.
> But I can't see these linking options on the running link:

of course unopkg.bin does not use nss libraries itself so no point
linking to them.  the problem is that libvcl is not properly linked
against nss.

i suggest you copy the -Wl,-z,defs line from linux.mk to solaris.mk then
rm -r workdir/*/LinkTarget and see what breaks then.