Description: The app crashes/doesn't run on macOS 11.7 (Big Sur) on Intel silicon. It reports: Check with the developer to make sure LibreOfficeDev works with this version of macOS. You may need to reinstall the application. Be sure to install any available updates for the application and macOS. Steps to Reproduce: 1. Start LibO 25.2 a1 2. 3. Actual Results: LibO crashes. Expected Results: Should run on macOS 11.7 (older macOS versions were announced to be deprecated, but not this one). Reproducible: Always User Profile Reset: No Additional Info: Cannot copy - as LO doesn't start.
Setting to critical.
(In reply to Martin Srebotnjak from comment #0) > Check with the developer to make sure LibreOfficeDev works... Did you download a nightly build? If yes, the nightly builds are not "codesigned" like release builds so tyou will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Yes. I can confirm.
(In reply to Dennis Roczek from comment #3) > Yes. I can confirm. I cannot confirm this bug. I downloaded the 2024-11-26 Intel nightly master build, installed it, did the xattr command in comment #2, and successfully launched it from the Finder: Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5e0c670e6534fee529ea46d520c6b442bea93aac CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded The problem for me is that I do not have any access to Intel machines so I don't know if the fact that the Intel nightly master build runs on my Silicon Mac running macOS Sequoia gives any hint as to what Intel Mac users are seeing. @Dennis Roczek does this bug only occur on macOS Big Sur? I don't have access to the LibreOffice nightly build servers but I think they are built on a macOS Sonoma machine with the "target macOS version" set to macOS Big Sur.
(In reply to Patrick (volunteer) from comment #4) > @Dennis Roczek does this bug only occur on macOS Big Sur? I don't have > access to the LibreOffice nightly build servers but I think they are built > on a macOS Sonoma machine with the "target macOS version" set to macOS Big > Sur. Yes, only mac11. I'm in contact with cloph regarding this issue since zwo weeks in the -qa irc channel. He even created a build and signed it using the offical build maschine (so we might have a "problem" in february).
(In reply to Dennis Roczek from comment #5) > Yes, only mac11. I'm in contact with cloph regarding this issue since zwo > weeks in the -qa irc channel. He even created a build and signed it using > the offical build maschine (so we might have a "problem" in february). Don't know if this helps, but I downloaded the LibreOffice 24.8.3 Intel release and I used the otool -l /path/to/soffice exectable to compare what "target macOS version" and "SDK version" are used in that release and the latest Intel nightly master build: LibreOffice 24.8.3 Intel release: cmd LC_BUILD_VERSION cmdsize 32 platform 1 minos 10.15 sdk 13.1 ntools 1 tool 3 version 820.1 2024-11-26 Intel nightly master build: cmd LC_BUILD_VERSION cmdsize 32 platform 1 minos 10.15 sdk 14.4 ntools 1 tool 3 version 1053.12 So, both are targeting macOS Catalina as the "minos" but the nightly master build is using a newer "sdk" (i.e. a newer version of Xcode). I wonder if the nightly master Intel machine had any recent changes like a system or Xcode update? For comparison, the LibreOffice 24.8.3 Silicon release was built with the following so maybe it is worth trying to install an even newer (or older) version of Xcode on the Intel nightly build servers?: cmd LC_BUILD_VERSION cmdsize 32 platform 1 minos 11.0 sdk 15.1 ntools 1 tool 3 version 1115.7.3
My report is based on the official alpha builds as available here (and not on some nightly builds): https://dev-builds.libreoffice.org/pre-releases/mac/x86_64/?C=M&O=D The source code is here: https://dev-builds.libreoffice.org/pre-releases/src/?C=M&O=D
(In reply to Martin Srebotnjak from comment #7) > My report is based on the official alpha builds as available here (and not > on some nightly builds): > https://dev-builds.libreoffice.org/pre-releases/mac/x86_64/?C=M&O=D Can anyone with macOS Big Sur running on Intel test if the nightly master build also has the same bug? If yes, then maybe it is possible to bibisect this?
(In reply to Patrick (volunteer) from comment #8) > Can anyone with macOS Big Sur running on Intel test if the nightly master > build also has the same bug? If yes, then maybe it is possible to bibisect > this? OK. So I downloaded the Intel pre-release build and on my Silicon macOS Sequoia it crashes immediately after Rosetta converts all of the Intel binaries to Silicon. When run from the command line I see the following: Referenced from: <53174C41-E4FD-3A70-A46A-5B19FAEE7ED7> /Applications/LibreOfficeDev.app/Contents/Frameworks/libraptor2-lo.0.dylib Reason: tried: '/usr/local/lib/libicuuc.dylib.75' (no such file), '/usr/lib/libicuuc.dylib.75' (no such file, not in dyld cache) (terminated at launch; ignore backtrace) So, for me, the Intel nightly master builds work but no the Intel prerelease build. So I ran the following against the Intel prerelease build: % otool -L /Applications/LibreOfficeDev.app/Contents/Frameworks/libraptor2-lo.0.dylib /Applications/LibreOfficeDev.app/Contents/Frameworks/libraptor2-lo.0.dylib: /@.__________________________________________________OOO/lib/libraptor2-lo.0.dylib (compatibility version 1.0.0, current version 1.0.0) @__________________________________________________URELIB/libicuuc.dylib.75 (compatibility version 75.0.0, current version 75.1.0) If I run the following against the Intel LibreOffice 24.8.3 release I get the following similar but different output: /@.__________________________________________________OOO/lib/libraptor2-lo.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 70.1.0) So, my maybe the "@__________________________________________________URELIB" in the Intel prerelease build might be confusing the macOS library loader? Not sure why those are slowing up in 25.2 but not in 24.8.3.
(In reply to Patrick (volunteer) from comment #8) > (In reply to Martin Srebotnjak from comment #7) > > My report is based on the official alpha builds as available here (and not > > on some nightly builds): > > https://dev-builds.libreoffice.org/pre-releases/mac/x86_64/?C=M&O=D > > Can anyone with macOS Big Sur running on Intel test if the nightly master > build also has the same bug? If yes, then maybe it is possible to bibisect > this? Yes, I can confirm same behavior also with nightly master.
I tried with the bisect repository but I can't reproduce it with Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 80d4ce197f2b9b38ce6af6ed18eb159edd24be5f CPU threads: 8; OS: macOS 11.7.10; UI render: default; VCL: osx Locale: en-US (en_ES.UTF-8); UI: en-US Calc: threaded
on the other hand, I do confirm it crashes with LibreOffice 25.2 Alpha downloaded from https://es.libreoffice.org/descarga/libreoffice/?type=mac-x86_64&version=25.2.0
(In reply to Xisco Faulí from comment #12) > on the other hand, I do confirm it crashes with LibreOffice 25.2 Alpha > downloaded from > https://es.libreoffice.org/descarga/libreoffice/?type=mac-x86_64&version=25. > 2.0 Do you have the configure/autogen arguments that was used to release that build? I could try do a cross-compiled Intel Mac release/signed build with master on my Silicon Mac running macOS Sequoia. Like you, the LibreOffice 25.2 Alpha Intel Mac release does crash on my Silicon Mac machine with macOS Sequoia so if I can reproduce the same crash from a local build, maybe I will be able to find what is causing this.
(In reply to Patrick (volunteer) from comment #13) > (In reply to Xisco Faulí from comment #12) > > on the other hand, I do confirm it crashes with LibreOffice 25.2 Alpha > > downloaded from > > https://es.libreoffice.org/descarga/libreoffice/?type=mac-x86_64&version=25. > > 2.0 > > Do you have the configure/autogen arguments that was used to release that > build? I could try do a cross-compiled Intel Mac release/signed build with > master on my Silicon Mac running macOS Sequoia. > > Like you, the LibreOffice 25.2 Alpha Intel Mac release does crash on my > Silicon Mac machine with macOS Sequoia so if I can reproduce the same crash > from a local build, maybe I will be able to find what is causing this. --with-distro=LibreOfficeMacOSX --host=x86_64-apple-darwin --build=x86_64-apple-darwin --with-privacy-policy-url=https://hub.libreoffice.org/privacy/ --disable-dependency-tracking --enable-release-build --enable-macosx-code-signing --with-lang=ALL I think this is pretty similar to the arguments used in a release. Probably --with-lang=ALL is not even necesary.
So doing several cross-compiles I keep coming back the following "dyld can't find libicuuc.dylib.75 when loading libraptor2-lo.0.dylib" crash: % otool -L /Applications/LibreOfficeDev.app/Contents/Frameworks/libraptor2-lo.0.dylib /Applications/LibreOfficeDev.app/Contents/Frameworks/libraptor2-lo.0.dylib: /@.__________________________________________________OOO/lib/libraptor2-lo.0.dylib (compatibility version 1.0.0, current version 1.0.0) @__________________________________________________URELIB/libicuuc.dylib.75 (compatibility version 75.0.0, current version 75.1.0) In LibreOffice 24.8.3 Intel, libraptor2-lo does *not* link to any version of libicuuc.dylib. But in the Intel 25.2.0 Alpha 1 and nightly master builds, it does link to the bundled libicuuc.dylib.75. So I have been trying to stop libraptor2-lo from linking to libicuuc.dylib (see debug patch below) but every time I "make clean && make" in external/redland, I see icuuc and xml2 linked in workdir/UnpackedTarball/raptor/src/Makefile: -L/Volumes/LOBuilds/lode/dev/core/workdir/UnpackedTarball/icu/source/lib -licuuc -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib -lxml2 -lz -lpthread -licucore -lm $(MEM_LIBS) Any idea where icuuc is getting inserted into the unpacked raptor configuration file? Below is the raptor configure command that is executed but no icuuc paths in the command yet configure is putting ICU_LIBS from LibreOffice's config_host.mk into raptors generated makefiles: cd /Volumes/LOBuilds/lode/dev/core/workdir/UnpackedTarball/raptor/ && unset Platform && export CCACHE_CPP2=1 CCACHE_DEPEND=1 && CFLAGS=" -O2 " LDFLAGS='' CPPFLAGS=" " echo ./configure --disable-gtk-doc --enable-parsers="rdfxml ntriples turtle trig guess rss-tag-soup" --without-www --without-xslt-config --build=x86_64-apple-darwin --host=x86_64-apple-darwin --prefix=/@.__________________________________________________OOO --enable-shared --disable-static && make
Ignore my last comment. I found the cause of libicuuc being added to libraptor-lo's link list: https://gerrit.libreoffice.org/c/core/+/177594 @Xisco: I tested with both with and without --disable-mergelibs but I don't have an Intel Mac with macOS Big Sur so would you be able to test a normal Intel build with this patch?
I prepped a baseline build of 25.2.0.0.alpha1 tag + Patrick's patch from https://gerrit.libreoffice.org/c/core/+/177594 here: https://dev-builds.libreoffice.org/macosx-debug/LibreOfficeDev_25.2.0.0.alpha1_MacOS_x86-64.dmg (signed & notarized)
I can confirm that this build by cloph works on my system. I does have some issues displaying the toolbar in Writer, however, but that is another bug, probably.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/24032fea95e84111ad60da7a8401eb1672c5f10d tdf#164047 Don't include libicuuc in libraptor2-lo link list on macOS It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.