Issues building LibreOffice 4.0.0.1

[Stephan Bergmann]

On 01/24/2013 10:43 PM, Henrik /KaarPoSoft wrote:
> On 01/24/2013 10:09 AM, Stephan Bergmann wrote:
>> 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:
>>>> 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".)
>
> Sorry about the confusion, my bad.
> I guess that misunderstandings aside we agree, that the paths looks
> oddly truncated.
> I have no clue why this would happen.
> Any ideas?

So I just ran into a problem with a libreoffice-4-0-0 build of mine on 
Mac OS X whose symptoms looked very much like the above, expanding LO 
bootstrap variables ($UserInstallation from bootstraprc in my case) to 
pathnames that were oddly truncated.  I tracked that down to bad calls 
to putenv (the code to expand bootstrap variables in 
sal/rtl/source/bootstrap.cxx tries to obtain values for that variables 
via getenv, among others, so it is susceptible to problems resulting 
from a broken environment), see 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=d841273ba54b173020aa8da18ba7841cf950c13c> 
"Do not call putenv with a temporary string argument."

While that fix is in Mac OS X specific code (so cannot be the cause of 
your Linux problems), there are more calls to putenv in the LO code 
base, and some of the might be broken in a similar way.

Stephan