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
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
