Re: Issues building LibreOffice 4.0.0.1

On 01/24/2013 12:33 AM, Henrik /KaarPoSoft wrote:
> On 01/23/2013 04:54 PM, Stephan Bergmann wrote:
> > On 01/23/2013 08:31 AM, Henrik /KaarPoSoft wrote:
> I have attached the last 100 lines of build output leading to the error.

> /tmp/cc7x3xJF.ltrans0.ltrans.o:(.data.rel.ro._ZTI27SvxForbiddenCharactersTable[_ZTI27SvxForbiddenCharactersTable]+0x10):
>  undefined reference to `typeinfo for salhelper::SimpleReferenceObject'
> collect2: error: ld returned 1 exit status
> make[2]: *** 
> [/home/kaarpux/kaarpux/linux/build/opt/libreoffice-4.0.0.1/workdir/unxlngx6.pro/LinkTarget/Library/libchartcontrollerlo.so]
>  Error 1

leaves me clueless.  I see nothing in chart2 that uses 
SvxForbiddenCharactersTable (except for an apparently unused #include I 
just killed on master with 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=d71e8fb17bd008751909ef2fabc6ff4f1e2db187> 
"Unused #include."

> > Depending on what you have in /opt, your autogen.lastrun's
> >
> > > # Pick up dependencies in /opt
> > > CPPFLAGS="-I/opt/include"
> > > LDFLAGS="-L/opt/lib"
> > > LD_LIBRARY_PATH="/opt/lib"
> >
> > could be the source of lots of trouble.
>
> What kind of trouble are you referring to?

For example, providing your own LDFLAGS bypasses some settings the LO 
build system would otherwise do for you, cf.

> gb_LinkTarget__get_ldflags=$(if $(LDFLAGS),$(LDFLAGS),$(call gb_LinkTarget__get_debugldflags,$(1)))

in solenv/gbuild/LinkTarget.mk.  And with libraries found on 
LD_LIBRARY_PATH taking precedence over libraries found via RPATH 
settings, any executables built and run during the LO build can 
erroneously pick up libraries from LD_LIBRARY_PATH instead of ones from 
its own build.  Stuff like that.

> > > Also some unittests fail, which I have then disabled.
> > > Further subsequenttest also fails.
> > > And the final product fails just after showing the splash screen.
> >
> > Your strace lines like
> >
> > > 9579  08:05:59.537424 openat(AT_FDCWD,
> > > "/opt/kaarpux/libreoffice-4.0.0.1/lib/libreoffice/program/../program/r",
> > > O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file
> > > or directory)
> > > 9579  08:05:59.537514 open("dkten-US.res", O_RDONLY) = -1 ENOENT (No
> > > such file or directory)
> > > 9579  08:05:59.537672
> > > access("/opt/kaarpux/libreoffice-4.0.0.1/lib/libreoffice/program/../progra",
> > >
> > > F_OK) = -1 ENOENT (No such file or directory)
> > > 9579  08:05:59.537725
> > > access("/opt/kaarpux/libreoffice-4.0.0.1/lib/libreoffice/program/unorc",
> > > F_OK) = 0
> > > 9579  08:05:59.537767
> > > access("/opt/kaarpux/libreoffice-4.0.0.1/lib/libreoffice/program/../program/boot",
> > >
> > > F_OK) = -1 ENOENT (No such file or directory)
> >
> > look oddly truncated.  For example, there should be a
> > .../program/boostraprc file that soffice.bin would indeed try to open
> > early on.
>
> Sorry, I just ran LO with --strace option.
> Attached is the corresponding output with strace -s2048
>
> Apart from not finding "libreoffice/program/../program/boot"
> the search for "libreoffice/program/../progra" (without trailing m)
> looks suspicious

With "oddly truncated" I did mean the filenames in the strace output 
(which should never be truncated by strace, regardless of any -s 
settings).  (And there's a typo in what I wrote, the non-truncated 
filename is "bootstraprc", not "boostraprc".)

Stephan