Issues building LibreOffice 4.0.0.1

[Stephan Bergmann]

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