#1

Hello,
After installing the program, tryed to start it by clicking “LibreOfficePortable,exe”. It started, there was the small intro window for 1 or two seconds, the progress bar up to the middle and gone.
Tryed to start the Calc program - just the same.
Previous versions working fine.
OS win 10 pro, 19405.3930 22H2 x64.
What went wrong ?
Answers will be appreciated,
Thanks
Motim
PS. Made short screenshot to demonstrate the problem. This intro is on the screen for a second or two, the progress bar stands as on the picture, stops at the middle and all gone.

LibreOffice 24.2.0 not startingt screenshot
LibreOffice 24.2.0 not startingt screenshot704×268 44.7 KB

#2

You could try forcing user data to be regnerated and see if that works.
I would start by renaming the .\PortableApps\LibreOfficePortable\Data\ folder and then start LibreOffice again. This should force LibreOffice to regenerate the Data folder. Be aware if you do this it will wipe you user data for LibeOffice Portable.

Also note that LibeOffice Portable will share the same Shared Python sitepackages as a Installed version Of LibreOffice uses.

If you can get LibreOffice started and use the APSO extension, in the console, you can find the Python paths a follows.

import sys
import pprint
pprint.pprint(sys.path)

I would think that any shared python path would be very unlikely to be creating an issue.

#3

I installed LibreOffice PortableApps portable to my usb flash drive.

Then I copied in someplace on my c:\ drive and tried to run it from there.

It works from the usb flash drive.

It crashes from the c:\ drive.

I tried to remove the ‘Data’ folder (C:\path_to\LibreOffice\LibreOfficePortable_24.2.3_MultilingualStandard.paf\Data) and it did get recreated but it still crashed the same way.

APPCRASH

CrashOnLaunch

#4

EDIT: It was NOT the copy after all. It was the PATH LENGTH.

I copied from

e:\1234\LibreOffice\LibreOfficePortable_24.2.3_MultilingualStandard.paf\

to

c:\1234567890123456\12345678\LibreOffice\LibreOfficePortable_24.2.3_MultilingualStandard.paf\

And that made the path long enough that LibreOffice crashed.

Original:
I discovered the problem. It is because you can change the DRIVE LETTER of a PortableApps-installed app but not the rest of the path.

#5

When you wrote that, I immediately got a deja vu feeling. And indeed, there was tdf#157254; but I fixed it for 24.2 (and even for 7.6.2). However, if you have a reproducible scenario that really depends on path length (as opposed to the PortableApps’ own restriction, which you cite later), then please file a bug report (and CC me there).

#6

The PortableApps people are convinced that it’s a LibreOffice problem, not a PortableApps problem.

I can’t do this experiment at the moment, but LibreOffice installs into C:\Program Files\LibreOffice\

Changing that install location to something that’s 100 chars or so long and seeing if it crashed seems like it would provide diagnostic guidance.

Also, it’s easy to install the PortableApps version of LibreOffice:

https://portableapps.com/redir2/?a=LibreOfficePortable&s=s&p=https://download.documentfoundation.org/libreoffice/portable/24.2.3/&d=pb&f=LibreOfficePortable_24.2.3_MultilingualStandard.paf.exe

(that link I pasted is being transformed into a link to the mirror…well it was in the preview, but not when I look at the actual post)

I suppose this is without debug symbols, but running it in a debugger and observing the crash may provide a knowledgeable person with enough information to tell whether it’s a PortableApps problem or LibreOffice problem.

Again, I wish I could perform these tests, but at this time I can’t.

#7

If you install normal LibreOffice, you can choose any path you want. You can install it into a directory like “c:\1234567890123456\12345678\LibreOffice\LibreOffice_NOT_Portable_24.2.3_MultilingualStandard”, or whatever - and it will start. So no, this is definitely not a direct LibreOffice problem. PortableApps could of course create some environment that uncovers the problem in LibreOffice, but then, it’s not easy to debug what they packaged - the binaries are modified, we have no symbols for them, they start extra processes (extra soffice.bin), so no, it’s not something easy to investigate.

But the most important is: if the problem isn’t important enough for users to file it, it is definitely not important enough to look at it.