Description: (not sure if sdk is the right component!) currently I've tried https://gitlab.com/ojwb/lloconv on macOS, while it compiles and runs it actually runs into failures with `lok_cpp_init`. Olly Betts did write me a simple reproducer which did compile on macOS but actually fails to run. The reproducer can be downloaded here: https://gitlab.com/ojwb/lloconv/uploads/98373168f73e762ee9f6c245606f6944/loktest.cc https://gitlab.com/ojwb/lloconv/-/issues/11#note_703189297 and I compiled it on macOS with: g++ -Wall -W -g -O2 loktest.cc -o loktest -ldl -I $HOME/libreoffice/include and i did run it w Steps to Reproduce: get https://gitlab.com/ojwb/lloconv/uploads/98373168f73e762ee9f6c245606f6944/loktest.cc 1. compile: g++ -Wall -W -g -O2 loktest.cc -o loktest -ldl -I $HOME/libreoffice/include 2. file: echo hello world > in.txt 3. run: LO_PATH=/Applications/LibreOffice.app/Contents/Frameworks/ ./loktest in.txt out.html 3. Actual Results: hangs at Calling lok_cpp_init() Expected Results: ``` Calling lok_cpp_init() lok_cpp_init() succeeded Calling documentLoad() No language allowlisted, turning off the language support. documentLoad() succeeded Calling saveAs() saveAs() succeeded deleting Document deleting Office Done ``` and of course created a html file Reproducible: Always User Profile Reset: No Additional Info: I tested it against libreoffice-7.2.1.2 and libreoffice-7.2.2.2 btw. lldb prints the following lines in a loop: 2021-10-14 14:03:01.400588+0200 loktest[48489:298492] [General] nextEventMatchingMask should only be called from the Main Thread! 2021-10-14 14:03:01.401133+0200 loktest[48489:298492] [General] ( 0 CoreFoundation 0x00007fff205f21db __exceptionPreprocess + 242 1 libobjc.A.dylib 0x00007fff2032bd92 objc_exception_throw + 48 2 AppKit 0x00007fff22d7e516 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 4389 3 AppKit 0x00007fff22d6fc69 -[NSApplication run] + 586 4 AppKit 0x00007fff22d43e6c NSApplicationMain + 816 5 libvclplug_osxlo.dylib 0x00000001159532e2 _ZN15AquaSalInstance10SVMainHookEPi + 178 6 libvcllo.dylib 0x0000000103e0590d _Z10ImplSVMainv + 109 7 libsofficeapp.dylib 0x0000000100434a38 soffice_main + 248 8 libsofficeapp.dylib 0x0000000100Process 48489 stopped so it looks like it loads the vcl dylib over and over again
Does this problem persist currently? It's been a while and this report sadly still is unconfirmed.
I don't have a mac, but I've tested in github actions and libreofficekit still seems broken on macos. Things have improved marginally as it now throws an exception instead of hanging: Calling lok_cpp_init() *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow should only be instantiated on the main thread!' *** First throw call stack: ( 0 CoreFoundation 0x000000019ddbaccc __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000019d8a2788 objc_exception_throw + 60 2 CoreFoundation 0x000000019dddfc48 _CFBundleGetValueForInfoKey + 0 3 AppKit 0x00000001a15ad294 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 188 4 AppKit 0x00000001a15ad1cc -[NSWindow initWithContentRect:styleMask:backing:defer:] + 48 5 AppKit 0x00000001a185d1e0 -[NSComboBoxWindow initWithContentRect:comboBoxCell:] + 88 6 AppKit 0x00000001a185cbd8 -[NSComboBoxCell initPopUpWindow] + 896 7 AppKit 0x00000001a18ae404 -[NSComboBoxCell initTextCell:] + 100 8 libvclplug_osxlo.dylib 0x0000000106eb9f60 _ZN15AquaSalInstanceC2Ev + 448 9 libvclplug_osxlo.dylib 0x0000000106eb9d30 create_SalInstance + 248 10 libvcllo.dylib 0x0000000105287e20 _ZN12_GLOBAL__N_111tryInstanceERKN3rtl8OUStringEb + 212 11 libvcllo.dylib 0x0000000105287be8 _Z17CreateSalInstancev + 272 12 libvcllo.dylib 0x00000001052d6668 _Z7InitVCLv + 140 13 libvcllo.dylib 0x00000001052d6380 _Z10ImplSVMainv + 328 14 libsofficeapp.dylib 0x000000010070c4d8 soffice_main + 216 15 libsofficeapp.dylib 0x0000000100752e38 _ZL12lo_startmainPv + 52 16 libuno_sal.dylib.3 0x00000001008ec69c _ZL21osl_thread_start_ImplPv + 128 17 libsystem_pthread.dylib 0x000000019dc66f94 _pthread_start + 136 18 libsystem_pthread.dylib 0x000000019dc61d34 thread_start + 8 ) libc++abi: terminating due to uncaught exception of type NSException /Users/runner/work/_temp/a1d11d20-8921-4beb-89f9-c687f1d039b8.sh: line 2: 5369 Abort trap: 6 LO_PATH=/Applications/LibreOffice.app/Contents/Frameworks ./loktest in.html out.doc The repo with the test code is: https://github.com/ojwb/loktest (I've stuck a copy of the LOK headers in the repo as the homebrew LO package doesn't seem to include them.) Logs from the action (though they'll expire after a while): https://github.com/ojwb/loktest/actions/runs/8932805167
For the record (since the linked logs will expire eventually) the homebrew libreoffice package version used in my test was: LibreOffice_24.2.3_MacOS_aarch64.dmg
Sorry to be the bearer of bad news, but I can't see how LibreOfficeKit could work on macOS. Unlike Windows and Linux, there is no "headless" vcl implementation on macOS and headless mode is needed to run using LibreOfficeKit. In your .cc file, the main() function is the main thread of your application and the LibreOfficeKit calls that you make do their work on a secondary thread. But macOS only allows running a native event loop or using native windows and menus on the main thread. This is why the Windows and Linux implementations have a headless mode: to avoid creating a native event loop, windows, or menus. There are no native events processed and all drawing is done to offscreen image buffers, not windows. In constrast, macOS only has a desktop vcl implementation so native windows and menus are always created. I have done a little work with Collabora Office iOS (https://collaboraonline.github.io/) and that product uses the vcl/ios code which is a headless implementation that can run in a secondary thread. Maybe a headless vcl plugin for macOS could be written using the iOS implementation as a template. Unfortunately, this project is way too big for a hobbyist like. I don't know if anyone is funding engineers for this or not but someone will likely need to fund engineers or find volunteers to implement this.
*** Bug 151766 has been marked as a duplicate of this bug. ***
Did this work with a version earlier than 7.2.1.2? If it did, then we are talking about a regression? I would be pretty certain that projects like this worked up to some point, and then stopped working. The question then would be why?
(In reply to Alex Thurgood from comment #6) > Did this work with a version earlier than 7.2.1.2? > If it did, then we are talking about a regression? I would be pretty certain > that projects like this worked up to some point, and then stopped working. > The question then would be why? Did you notice that they're code is "stuck" while LibreOffice is in its native event queue? Their code is literally loading the LibreOffice code and running in their application's main thread. So, LibreOffice starts the native event loop. The event loop runs until LibreOffice terminates. I get it that there is interest that you can run a complex GUI application as a command line tool. And you can on Windows and Linux and iOS since they have a separate "headless mode" vcl code that never creates any native windows so there is no need to start a native event loop. It's pretty basic here: TDF and partners funded headless mode for Windows and Linux and iOS. No one funded a macOS headless mode. I don't have the time, funds, or even interest to fund this on macOS.
It's reasonable that not all platforms are supported, but it'd help users (and probably reduce the number of bug reports you'll need to mark as duplicates of this) if this limitation was clearly documented. Currently I can't see any mention of this in the docs - perhaps https://docs.libreoffice.org/libreofficekit.html would be a suitable place. Also LibreOfficeKitInit.h actually contains conditionals which appear to be there for macOS support, so anyone looking at the header would probably think it was intended to be supported - e.g.: #ifdef __APPLE__ #define TARGET_LIB "lib" "sofficeapp" ".dylib" #define TARGET_MERGED_LIB "lib" "mergedlo" ".dylib" #else #define TARGET_LIB "lib" "sofficeapp" ".so" #define TARGET_MERGED_LIB "lib" "mergedlo" ".so" #endif It'd be more helpful to fail to compile with a clear error on macOS, e.g: #ifdef __APPLE__ # error LibreOfficeKit not currently supported on macOS #endif Not sure if iOS defines __APPLE__ too, if so the condition would need to check for that case.
Created attachment 198454 [details] Patch that should error when compiling for any Apple OS other than iOS Not sure who handles that web page, but I do have a local iOS app build. The iOS app builds with the attached patch. Can anyone confirm that their LOKit-based build now fails with the attached patch? If the build now fails with "LibreOfficeKit is only supported on iOS", then I can submit the patch to LibreOffice. Note: you may need to tweak the paths at the top of the patch file. I changed the LOKit headers in a full LibreOffice build.
Created attachment 198455 [details] Newer version of patch in attachment #198454 [details] Oops. I forgot the iOS app builds in a separate branch that is a bit behind LibreOffice's master branch. So if the patch in attachment #198454 [details] fails to apply, try this one.
Thanks - I applied your patch to the loktest repo I used before (I just patched the copy of the headers already there as I don't have a LO git tree checked out to easily get hold of the latest versions). On macos that gives: In file included from loktest.cc:14: In file included from include/LibreOfficeKit/LibreOfficeKit.hxx:14: include/LibreOfficeKit/LibreOfficeKitInit.h:39:14: error: LibreOfficeKit is only supported on iOS #error LibreOfficeKit is only supported on iOS ^ include/LibreOfficeKit/LibreOfficeKitInit.h:204:44: error: use of undeclared identifier 'TARGET_LIB' imp_lib_size = partial_length + sizeof(TARGET_LIB) + sizeof(TARGET_MERGED_LIB) + 2; ^ include/LibreOfficeKit/LibreOfficeKitInit.h:204:65: error: use of undeclared identifier 'TARGET_MERGED_LIB' imp_lib_size = partial_length + sizeof(TARGET_LIB) + sizeof(TARGET_MERGED_LIB) + 2; ^ include/LibreOfficeKit/LibreOfficeKitInit.h:217:39: error: use of undeclared identifier 'TARGET_LIB' strncpy(imp_lib + partial_length, TARGET_LIB, imp_lib_size - partial_length); ^ include/LibreOfficeKit/LibreOfficeKitInit.h:237:43: error: use of undeclared identifier 'TARGET_MERGED_LIB' strncpy(imp_lib + partial_length, TARGET_MERGED_LIB, imp_lib_size - partial_length); ^ 5 errors generated. It seems unhelpful to trigger these additional errors - experienced C/C++ developers have probably learned to look at the first error first, but people just building the code may not and sometimes automated build systems just show you the tail of the log, so I tried a tweak: https://github.com/ojwb/loktest/commit/4f3aaf373de7c6178fe6ab9b63b04c01d86a5a11 With that I get: In file included from loktest.cc:14: In file included from include/LibreOfficeKit/LibreOfficeKit.hxx:14: include/LibreOfficeKit/LibreOfficeKitInit.h:36:14: error: LibreOfficeKit is only supported on iOS #error LibreOfficeKit is only supported on iOS ^ 1 error generated. The error message seems potentially misleading as LibreOfficeKit *is* supported on other platforms (Linux and Microsoft Windows for example). I'm not sure if there actually are any other Apple platforms other than iOS and macOS, but if not then "is not supported on macOS" seems clearer. If there are maybe "is not supported on Apple platforms other than iOS" or something less cumbersome.
OK. I've got a patch that only triggers one compiler error and hopefully has clearer wording: https://gerrit.libreoffice.org/changes/core~180093/revisions/1/patch?zip Let me know if the above patch looks good or not.
Looks good, just "error: LibreOfficeKit is not supported on macOS" now: https://github.com/ojwb/loktest/actions/runs/12737867254/job/35499427169
(In reply to Olly Betts from comment #13) > Looks good, just "error: LibreOfficeKit is not supported on macOS" now: > > https://github.com/ojwb/loktest/actions/runs/12737867254/job/35499427169 OK. I have submitted the patch for review here: https://gerrit.libreoffice.org/c/core/+/180093
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/18e5d1ce26ab7a0fb41b8b64a0a732b5f81f3ed8 Related: tdf#145127 force error when compiling for unsupported Apple OSs It will be available in 25.8.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/d069b60587c73203749fe1333f87c529def1574d Related: tdf#145127 force error when compiling for unsupported Apple OSs It will be available in 24.8.5. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/e53560d5dc667515be382a34c0e4e3ef5badd9a0 Related: tdf#145127 force error when compiling for unsupported Apple OSs It will be available in 25.2.1. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2-0": https://git.libreoffice.org/core/commit/98f3ce113baca7026025538a9ff453931900ae2d Related: tdf#145127 force error when compiling for unsupported Apple OSs 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.