Self-explanatory output from a Terminal session: $ /Applications/LibreOffice.app/Contents/program/python Python 2.6.1 (r261:67515, May 22 2012, 08:19:34) [GCC 4.0.1 (Apple Inc. build 5494)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import uno Abort trap: 6 $ uname -a Darwin sekhmet.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
Created attachment 62516 [details] crash report
Hm ... for me, it seems to work. I have installed LibreOffice 3.5.4.2 (Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18) on MacOS X 10.6.8 locally to my user profile, i.e. at ~/Applications/LibreOffice/LibreOffice.app Therefore, the input and output of my Terminal session are: $ ~/Applications/LibreOffice/LibreOffice.app/Contents/program/python Python 2.6.1 (r261:67515, May 22 2012, 08:19:34) [GCC 4.0.1 (Apple Inc. build 5494)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import uno >>> That's it: no abort. This is the output from "uname -a" on my machine: Darwin <machine name>.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 This leads to the question: what is the (human readable) MacOS X version you use (probably 10.7.x)? Maybe this crash has something to do with the MacOS X version? (I don't know why, but I see no other important difference between your and my configuration; the LibreOffice-provided Python seems to be identical.)
$ uname -a Darwin sekhmet.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 Yup it's 10.7.4. It impacts unoconv (https://github.com/dagwieers/unoconv/issues/27) and reports over there corroborate that 'import uno' works on Snow Leopard but fails with an abort on Lion.
(In reply to comment #3) > It impacts unoconv (https://github.com/dagwieers/unoconv/issues/27) and > reports over there corroborate that 'import uno' works on Snow Leopard > but fails with an abort on Lion. OK, IMHO the information in https://github.com/dagwieers/unoconv/issues/27 is sufficient to set this report's Status field to NEW (some comments in the quoted discussion talk explicitely about LibreOffice on MacOS X 10.7). To sum it up: if I understand correctly, this is not a bug in unoconv (as the quoted discussion seems to suggest at the very (!) first glance; but then this would be NOTOURBUG), but it is a bug in LibreOffice itself which prevents the LibreOffice-provided Python from working together with Uno, and therefore also makes unoconv stop working. However, this issue seems to be present on MacOS X 10.7 (Lion) only. @Loic Nageleisen: is my summary halfway correct?
> is my summary halfway correct? Absolutely. unoconv only crashes insofar as it imports uno and the problem can readily be replicated with only LibreOffice and its bundled python. I have no Snow Leopard at hand but I can confirm the crash on three distinct Lion machines.
@Stephan Bergmann, @Thorsten Behrens: You are our UNO and MacOS experts. I don't know who is our Python expert, so I insert (only) your addresses into the CC list. Please take a look at this issue. It breaks Python access to UNO completely on MacOS X 10.7 (and maybe elsewhere). Thank you very much!
At least on Mac OS X 10.7.4, the dlopen of libpyuno.dylib from pyuno.so (pyuno/source/module/pyuno_dlopenwrapper.c) fails with a dlerror of dlopen(/Users/stephan/Desktop/LOdev.app/Contents/MacOS/libpyuno.dylib, 10): Symbol not found: _sqlite3_wal_checkpoint Referenced from: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork Expected in: /Users/stephan/Desktop/LOdev.app/Contents/MacOS/libsqlite3.dylib in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork <http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc82cf021f76ea83ff7a4bcb2d7525f2e111f0cc> "Make PyUNO work --with-macox-version-min-required=10.6" on recent master towards LO 3.7 fixes this when *building* on Mac OS X 10.7.4, but not when *running* a stock build (based on the 10.4 SDK) on Mac OS X 10.7.4. Whether it would be OK to adapt that fix to always build LO on Mac OS X against system libsqlite3.dylib instead of one from LO's nss module, I do not know. I do not have a baseline Mac OS X 10.4 to check whether its system libsqlite3.dylib (if any) would be sufficient.
According to a thread [0] that turn up on a google incantation, Tiger does have sqlite3 bundled. > Tiger comes with sqlite3 pre-installed: /usr/lib/libsqlite3.dylib >> Is sqlite3 installed on Tiger or just included with it? > It's installed. It is part of BaseSystem.pkg - i.e. it is on every Tiger machine. Also, this StackOverflow thread [0] gives hints as to ways to link it from the SDK on build > If you must link with Tiger's sqlite3, all you need to do is add this to your Other Linker Flags: > -l/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libsqlite3.dylib From other threads [2] I could gather that it could be sqlite 3.1.3. Finally, in Apple's open source browser one can find the sqlite source they used for e.g 10.4.11 [3]. The VERSION file confirms 3.1.3. [0] http://hintsforums.macworld.com/showthread.php?t=63805 [1] http://stackoverflow.com/questions/1474176/how-to-link-tigers-sqlite3-library-in-xcode [2] http://forums.pragprog.com/forums/66/topics/408 [3] http://opensource.apple.com/source/SQLite/SQLite-28/
Just in case this is of interest: on MacOS X 10.6(.8), the preinstalled /usr/lib/libsqlite3.dylib seems to have version 3.6.12.
also see mailing list thread started at <http://lists.freedesktop.org/archives/libreoffice/2012-June/033825.html> "Using system libsqlite3.dylib on Mac OS X? (fdo#50682)"
Following a comment of someone able to hack hos way into making unoconv behave on Lion and combined with the fact that it comes from some dylib, I had some progress[0] made on making 'import uno' working. I commented the following lines in /Applications/LibreOffice.app/Contents/MacOS/python: DYLD_LIBRARY_PATH=$sd_prog:$sd_prog/../ure-link/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH} export DYLD_LIBRARY_PATH import uno does work, and I tested a small number of scripts to validate it's really working (e.g Hello World from [1]). So a possible workaround would be to negatively test like so before setting DYLD_LIBRARY_PATH. if perl -e '`uname -s -r` =~ /Darwin 11\.\d+\.\d+/ and exit 1'; then DYLD_LIBRARY_PATH=$sd_prog:$sd_prog/../ure-link/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH} export DYLD_LIBRARY_PATH fi [0] https://github.com/dagwieers/unoconv/issues/27#issuecomment-6490497 [1] http://www.openoffice.org/udk/python/python-bridge.html#tutorial
Created attachment 63319 [details] Skip setting DYLD_LIBRARY_PATH on Lion Workaround. Appears to be working but requires further evaluation.
(In reply to comment #11) > I commented the following lines in > /Applications/LibreOffice.app/Contents/MacOS/python: > > DYLD_LIBRARY_PATH=$sd_prog:$sd_prog/../ure-link/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH} > export DYLD_LIBRARY_PATH > > import uno does work, and I tested a small number of scripts to validate it's > really working (e.g Hello World from [1]). Ha, right, /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork picking up my LO's /Users/stephan/Desktop/LOdev.app/Contents/MacOS/libsqlite3.dylib instead of the system one as recorded with an installpath in CFNetwork is likely not due to some other LO lib in that process already having loaded LO's libsqlite3.dylib via installpath, but rather due to DYLD_LIBRARY_PATH overriding any recorded installpaths anyway. That means the best fix might be to just replace all mention of DYLD_LIBRARY_PATH in the python script with DYLD_FALLBACK_LIBRARY_PATH (see man page for dyld(1)). Can you try that? (It was likely pure luck that your "small number of scripts" kept working after removing the DYLD_LIBRARY_PATH block completely.)
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a164d246f2ed941fbdef19ec5b47dac1bab25509 fdo#50682: Setting DYLD_LIBRARY_PATH in python script appears unnecessary
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b4ba164264de30735941bfbb87f36ec5ca81ea36&g=libreoffice-3-6 fdo#50682: Setting DYLD_LIBRARY_PATH in python script appears unnecessary It will be available in LibreOffice 3.6.
On closer inspection, setting DYLD_LIBRARY_PATH in LO's python wrapper script appears to be completely unnecessary after all. I intend to get the above fix for master and libreoffice-3-6 (see comment 14 and comment 15) backported to libreoffice-3-5 and libreoffice-3-5-5 as well, see <http://lists.freedesktop.org/archives/libreoffice/2012-June/034010.html> "[REVIEW-3-5][REVIEW-3-5-5] Using system libsqlite3.dylib on Mac OS X? (fdo#50682)."
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cf5ac1ad17bd8d2e9c8b585254302ecc053a9547&g=libreoffice-3-5 fdo#50682: Setting DYLD_LIBRARY_PATH in python script appears unnecessary It will be available in LibreOffice 3.5.6.