Did 24.8.5 work fine? What if you launch from the command line with `libreoffice --safe-mode`?

Still using 24.2.6.2… Some availability messages overlooked?

Error message -bash: libreoffice: command not found whatever the directory (~, Applications, …)

(In reply to jp.lange from comment #2)
> Still using 24.2.6.2… Some availability messages overlooked?
> 
> Error message -bash: libreoffice: command not found whatever the directory
> (~, Applications, …)

Then adjust the path, so it's pointing to the correct location.

Not sure what's with the Linux-style tips but this bug sounds like you downloaded the Mac Silicon installer instead of the Mac Intel installer.

A few months ago, Mac Silicon became the default download. Before that, Mac Intel was the default. So I would recommend checking that you selected "macOS (Intel)" from the listbox on the LibreOffice download page.

For some unknown reason, LibreOffice staff do *not* provide a single installer for both Mac Silicon and Mac Intel. Despite this being the Apple standard, LibreOffice continues to do their own unique approach.

(In reply to Buovjaga from comment #3)
> Then adjust the path, so it's pointing to the correct location.

FYI. There is no "libreoffice" executable in LibreOffice on macOS so your Linux steps are garbage. Even if it was, most users do not know about the Terminal as it is tucked away in the Finder in the /Applications/Utilities folder.

But if you want to use the Terminal, you use the following:

/Applications/LibreOffice.app/Contents/MacOS/soffice

Patrick

You were right.

I got the “Bad CPU type in executable” error message issuing the command in Terminal.

I reloaded LibreOffice paying attention to the architecture and it's now working, including the translated interface.

Thanks a lot.

J–P

PS: btw, I have been tinkering with computers very likely before most of you were born (early '70s) and used be a Unix (a. o.) sysadmin for over 10 years (mainly Sun microsystems)

(In reply to Patrick (volunteer) from comment #5)
> (In reply to Buovjaga from comment #3)
> > Then adjust the path, so it's pointing to the correct location.
> 
> FYI. There is no "libreoffice" executable in LibreOffice on macOS so your
> Linux steps are garbage. Even if it was, most users do not know about the
> Terminal as it is tucked away in the Finder in the /Applications/Utilities
> folder.

I know there is no such executable, it was a pseudo-command to give a point of reference. It was the best I could do in a hurry as a non-macOS user.

Marking as resolved.

(In reply to Buovjaga from comment #7)
> I know there is no such executable, it was a pseudo-command to give a point
> of reference. It was the best I could do in a hurry as a non-macOS user.

Sorry I didn't make it clear, but I cc'd you and cloph because it was obvious to me that this bug was another case of the recurring download problem for Mac Intel users since LibreOffice switched the default Mac chip earlier this year.

Maybe this isn't on TDF staff's radar, but it is clear to me that a steady stream of Mac Intel users now download the installer from the LibreOffice site like they always have and, after they install it, they are dead in the water. That can't be helping TDF donations.

This wasn't much of a problem before the switch since Apple gave Mac Silicon users a smooth way to make Mac Intel applications run. But Mac Intel users have no such alternative and are left wondering why the process they have always used to download LibreOffice has now overwritten their working LibreOffice with an unrunnable one. And worse, redownloading the older version they were using doesn't work either.

I don't think the new support load that this switch caused is going to go away on its own anytime soon. I admit that I still don't understand why TDF staff only ships a universal installer in the Mac App Store and not the LibreOffice download page but the current combination of non-universal installer and Mac Silicon as the default chip have created frustration and confusion for Mac Intel users.

Whether you like it or not, you and cloph are the owners of this problem. Shipping a universal installer would eliminate this problem entirely. But if TDF staff are against that, then both of you should at least bear some responsibility for handling the support load that your approach has created.