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.