Bootstrap.bootstrap() fails with the error message you see below because Java 7 on OSX is 64bit only and the libjpipe.jnilib is 32bit only. Please generate universal (32 and 64bit) binaries for the OSX libraries.
java.lang.UnsatisfiedLinkError: /Users/claudio/Applications/LibreOffice.app/Contents/ure-link/lib/libjpipe.jnilib: dlopen(/Users/claudio/Applications/LibreOffice.app/Contents/ure-link/lib/libjpipe.jnilib, 1): no suitable image found. Did find:
/Users/claudio/Applications/LibreOffice.app/Contents/ure-link/lib/libjpipe.jnilib: mach-o, but wrong architecture
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
@ Stephan Bergmann, Tor Lillqvist:
Hi Stephan and Tor,
IIRC you have experience in UNO stuff and/or 64 bit compilation resp.
Any ideas about this issue? Or do you know who can help here?
Thank you very much! (And wish you a merry Xmas and a happy new year ;-)
Things like a 64bit libjpipe.jnilib would only be one part of a complete picture. To allow in-process UNO communication, a 64bit C++ UNO bridge for Mac OS X would be needed too. In short, this ultimately boils down to a new LO "port" for 64bit Mac OS X (which has repeatedly been discussed but never actually been started). Changed the summary accordingly.
Actually, it *has* been started. Try the --enable-64-bit option and build against a current SDK. Basically what prevents it from working is the unfinishedness of the --enable-coretext thing. For 64-bit code all the deprecated stuff is really gone, honestly. Not like for 32-bit code where some declarations are gone from headers but the API is still present in libraries ("frameworks"). So the code definitely needs to use CoreText. As for the C++/UNO bridge, I think it might even work. At least I vaguely recall seeing LO start up as a 64-bit program fine, which probably it wouldn't manage to do unless the bridge worked? (Sure, it soon gets stuck or crashes because of the bugs in our CoreText code).
A quick status update: The CoreText code no longer gets stuck in a loop or crashes, but it doesn't work well enough for a CoreText-using LibreOffice to be usable. (Some problems with the treatment of trailing spaces of text snippets passed to CoreText for layout, I think.) Otherwise LibreOffice seems to work as 64-bit code. (But I haven't tested any complicated things...)
*** Bug 47031 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> A quick status update: The CoreText code no longer gets stuck in a loop or
> crashes, but it doesn't work well enough for a CoreText-using LibreOffice to
> be usable. (Some problems with the treatment of trailing spaces of text
> snippets passed to CoreText for layout, I think.) Otherwise LibreOffice
> seems to work as 64-bit code. (But I haven't tested any complicated
If the build is available somewhere I can provide feedback I guess.
Are these builds now the official 4.1 builds? I cannot see any other OS X build than this one.
And this worries me a bit, since all the other directories are empty, and some fixes which have probably merged to the 32-bit builds have not been merged to this build yet.
Nothing "official" about them. And 4.1 is not even released yet.
My 64-bit builds are built from the LibreOffice sources, the master branch, so I don't really know what "fixes which have probably merged to the 32-bit builds" you are talking about. Could you be more specific? And if you are just guessing or spreading rumours, stop.
Hey - I am not spreading any rumours, I was just wondering why there are no 32-bit master builds...
Anyway, I was checking Bug 62384, which is already available in LO 18.104.22.168, and the master at that time when it was pushed, but not available in your build. -- I double checked it now, and it is included -- but due to a font drawing bug, glyph does not appear. I guess I'll create a bug about that. Sorry about the noise.
There are no 32-bit master builds because nobody has volunteered to produce such builds. There is no central authority that decides what nightly builds to produce and then delegates that tasks to underlings. It is quite the opposite; anybody can run a tinderbox, and if he or she seems at least a bit reliable, can be allowed to upload daily builds for redistribution (I assume; I am not even a member of TDF).
In other words, if you have a suitable Mac and and maybe a dozen of gigs of disk space available, you could well run a tinderbox yourself and upload dailies.
*** Bug 38757 has been marked as a duplicate of this bug. ***
*** Bug 66014 has been marked as a duplicate of this bug. ***
4.2.0 Alpha 1 only works on 10.8 or newer. Since 64-bit architecture is present from 10.6, shouldn't we support 10.6 as base platform?
Or is this a bug?
Dear Emir, it is not a bug that the baseline for 64-bit LibreOffice on OS X is 10.8. It was decided for some technical reasons in following ESC call: http://nabble.documentfoundation.org/minutes-of-ESC-face-to-face-td4075224.html
On 4.2.0..4 release build, pre-existing ODB files no longer function because of this bug and produce the exact same error message when a user has Java 7 installed instead of the Apple 1.6.0_65.
Since LO 4.2 there now is a 64-bit build for OS X (>= 10.8), <http://donate.libreoffice.org/home/dl/mac-x86_64/4.2.0/en-US/LibreOffice_4.2.0_MacOS_x86-64.dmg>. And it is known to work at least together with Apple's (64-bit) JVM.
This issue has a somewhat mixed history about 64-bit builds for OS X in general and in combination with Oracle Java 7 (which is only available as a 64-bit JVM) in particular. However, I'm inclined to take this bug for the former (which would match its blocking of issue 44123) and thus mark it FIXED now.
If there are any problems with a 64-bit LO build on Mac OS X in combination with Oracle Java 7 (like issue 74683 describes), please take that to another issue.
(In reply to comment #18)
> If there are any problems with a 64-bit LO build on Mac OS X in combination
> with Oracle Java 7 (like issue 74683 describes), please take that to another
...and note part (1) of <https://bugs.freedesktop.org/show_bug.cgi?id=74597#c3>