Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not working on Mac #27

Closed
sotis opened this issue Feb 14, 2012 · 82 comments

Comments

Projects
None yet
@sotis
Copy link

commented Feb 14, 2012

I get the following error on my macbook:

unoconv: Cannot find a suitable pyuno library and python binary combination in /Applications/OpenOffice.org.app/Contents
ERROR: Please locate this library and send your feedback to:
http://github.com/dagwieers/unoconv/issues
No module named uno
unoconv: Cannot find a suitable office installation on your system.
ERROR: Please locate your office installation and send your feedback to:
http://github.com/dagwieers/unoconv/issues

I'm running OpenOffice.org 3.3.0 on Mac OS X Lion 10.7.2
My unoconv version is 0.5, it is placed in /usr/bin and given read and execute permissions

It fails if called directly, also if called with sudo

Searched for openoffice files and found:
pyuno.so at /Applications/OpenOffice.org.app/Contents/basis-link/program/pyuno.so
soffice.bin at /Applications/OpenOffice.org.app/Contents/MacOS/soffice.bin

@dagwieers

This comment has been minimized.

Copy link
Member

commented Feb 15, 2012

Arghl, yet another location to add to my search path, only for the office binary :-/ So someone decided to add 'MacOS' to the directory structure...

Can you tell me what the location is of the python.bin ? I am afraid I have to do another rewrite of the search-code just to accomodate for the possibility to have soffice.bin inside a MacOS folder. Let's hope the python binary is in that same folder...

@ghost ghost assigned dagwieers Feb 15, 2012

@sotis

This comment has been minimized.

Copy link
Author

commented Feb 15, 2012

Thanks for the quick reply Dag,

Here's what I've discovered so far:

First of all it looks like an operating system version issue rather than an office version one. My iMac which also runs Mac OS X Lion but has libreoffice installed, has the exact same problem.

Now, to make matters worse, it looks like there's no python.bin file

I tried to do a "locate python.bin" and a "find / -name python.bin -print" both with or without sudo and ended up empty hahnded. python.bin is nowhere to be found.
Is it possible that htey've changed the name of the file? Where is it generally supposed to be?
A python interpreter IS installed on my machine (python -V returns "Python 2.7.1") but that's the system one and I guess it's not the one you're after. It's in /usr/bin anyway as it should

@dagwieers

This comment has been minimized.

Copy link
Member

commented Feb 15, 2012

Ok, the reason why unoconv is looking for a python interpreter inside the LibreOffice installation path, is because that's the only guaranteed way to make sure python and the python UNO bindings are working together. In many cases, if the python UNO module has been compiled for a different python version, it fails to work.

Now, it is not required to have a python.bin, it might actually work with the python you have installed, especially if the LibreOffice and python interpreter come from the same "repository". Anyway, assuming this is the case for everyone I will add the MacOS case to the unoconv tool so you can test.

Can you test the newer version in Github ? Thanks !

@bartbunting

This comment has been minimized.

Copy link

commented Feb 15, 2012

Hi,

I have just pulled the latest version from git and the same issue appears to still be happening.

I have uncommented the debug line in unoconv and it gives the following output if that is helpfull?

unoconv
sysname=posix
platform=darwin
python=/usr/bin/python
python-version=2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)]
URE_BOOTSTRAP=vnd.sun.star.pathname:/Applications/LibreOffice.app/Contents/program/fundamentalrc
UNO_PATH=/Applications/LibreOffice.app/Contents/basis-link/program
PATH=/Applications/LibreOffice.app/Contents/program:/usr/local/Cellar/autoconf/2.68/bin/:/Users/bart/.rvm/gems/ruby-1.9.2-p290/bin:/Users/bart/.rvm/gems/ruby-1.9.2-p290@global/bin:/Users/bart/.rvm/rubies/ruby-1.9.2-p290/bin:/Users/bart/.rvm/bin:/Users/bart/bin:/usr/local/sbin:/usr/local/bin:/usr/local/texlive/2010/bin/universal-darwin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/sbin:/opt/local/bin:/usr/local/mysql/bin:/Library/Application Support/VMware Fusion
LD_LIBRARY_PATH=/Applications/LibreOffice.app/Contents/basis-link/program:/Applications/LibreOffice.app/Contents/basis-link/ure-link/lib
unoconv: Cannot find a suitable pyuno library and python binary combination in /Applications/LibreOffice.app/Contents
ERROR: Please locate this library and send your feedback to:
http://github.com/dagwieers/unoconv/issues
No module named uno
unoconv: Cannot find a suitable office installation on your system.
ERROR: Please locate your office installation and send your feedback to:
http://github.com/dagwieers/unoconv/issues

I also tried a simple script with just

import uno, unohelper

This fails because it can't find unohelper. It however works if I just have import uno.

I'm not familiar enough with python to know how to ask where it's finding uno though.

Anything else I can do to help debug?

@dagwieers

This comment has been minimized.

Copy link
Member

commented Feb 16, 2012

What worries me is that the output says: No module named uno

Also, the PATH still mentions /Applications/LibreOffice.app/Contents/program instead of /Applications/LibreOffice.app/Contents/MacOS, I thought I fixed that ? Are you sure soffice.bin is not inside /Applications/LibreOffice.app/Contents/program ? Maybe it is in 2 locations ?

By default (if you do not modify the path(s), it will look inside the normal search path for python libraries, I don't know what that is on MacOSX. If it can load the uno python module, it finds it there.

Normally there are 2 possibilities:

  • The LibreOffice installation comes with the (Linux) distribution, in this case using the distribution python is fine, and the python UNO bindings are installed in the normal location for python libraries
  • The LibreOffice installation comes from upstream (or a third party), in this case it is usually installed in /opt or /usr/local and it ships with its own python interpreter and the bindings are in /opt or in /usr/local. In this case we have to switch from the distribution python (which is invoked by unoconv) to the LibreOffice python using a module search path in the LibreOffice installation path.

Your case seems to:

  • lack a LibreOffice python binary
  • does ship with the UNO bindings in the LibreOffice installation path
  • also has the UNO bindings in the normal python search path, but lacking unohelper

I think the best course of action for me is to get rid of the dependency on unohelper, it's only needed for a few things, and I wonder if I can avoid needing it ? I do not understand how this is supposed to work on MacOSX though, I cannot believe the installation would be crippled to a point where the UNO bindings do not work. The most basic case is indeed starting python and import uno and import unohelper, when that works invoke soffice.bin as a listener. But the first part already fails...

@bartbunting

This comment has been minimized.

Copy link

commented Feb 16, 2012

Hi,

Here are the contents of the directories in question:

Maybe it gives a clew:

bart@bit:/Applications/LibreOffice.app/Contents$ls -1
Info.plist
Library
MacOS
PkgInfo
Resources
basis-link
program
share
bart@bit:/Applications/LibreOffice.app/Contents$cd MacOS
bart@bit:/Applications/LibreOffice.app/Contents/MacOS$ls -1
about.png
bootstraprc
fundamentalrc
intro.png
sbase
scalc
sdraw
services.rdb
setuprc
shell
simpress
smath
soffice
soffice.bin
sofficerc
swriter
testtool
unoinfo
unopkg
unopkg.bin
urelibs
versionrc
bart@bit:/Applications/LibreOffice.app/Contents/MacOS$

@dagwieers

This comment has been minimized.

Copy link
Member

commented Feb 16, 2012

Can you send me the output of find /Applications/LibreOffice.app/Contents by email ? Please also send me the output of find / -name "*uno.*". Both will give me a broader view of the installation of LibreOffice and potential UNO libraries :)

Thanks in advance !

@dagwieers

This comment has been minimized.

Copy link
Member

commented Feb 16, 2012

Bart, thanks again for your help. I think I nailed it, and know why it failed to work. I used to insert the UNO bindings path into the python search path so that python could import modules from the LibreOffice path. After improving unoconv and allowing to replace the python interpreter in memory with the LibreOffice python interpreter, being smart as I am, I removed the part that inserted this library-path because the LibreOffice python is compiled by default to hold this path in the search path.

But of course, this totally neglected your use-case (which I assumed was no longer needed) where the system python interpreter is used with the LibreOffice-provided UNO bindings. This should be fixed thanks to the following commit: 90db481

Can you test again ? Thanks !

@sotis

This comment has been minimized.

Copy link
Author

commented Feb 16, 2012

Sorry for disappearing guys, it has been a hell of a day for me yesterday.

Dag, the path /Applications/LibreOffice.app/Contents/program DOES exist! in fact 'program' is a symbolic link to 'MacOS', so the same content in both locations
I did an ls -laR /Applications/LibreOffice.app/Contents/ as root on my iMac, but I can't submit it from here (I guess there's a size limit for comments?). I can also do the same with my MacBook Air (I have OS X Lion on both machines, but iMac has LibreOffice and MacBook has OpenOffice installed).

How can I send you the listing (if it can actually be of any help)? It's a 589K txt file or a 43K zip file

I can even provide a teamviewer connection to see its behavior live

@bartbunting

This comment has been minimized.

Copy link

commented Feb 16, 2012

Hi Dag,

Sorry to say it appears not to have worked here :(.

git log HEAD | head
commit bd9bec3
Author: Dag Wieers dag@wieers.com
Date: Thu Feb 16 20:44:44 2012 +0100

- Revert -D / --daemon feature
- Fix disable listener on existing LibreOffice GUI

commit 09f97c8
Merge: 3e9711e a84878d
Author: Dag Wieërs dag@wieers.com
bart@bit:/src/unoconv$./unoconv
unoconv: Cannot find a suitable pyuno library and python binary combination in /Applications/LibreOffice.app/Contents
ERROR: Please locate this library and send your feedback to:
http://github.com/dagwieers/unoconv/issues
No module named uno
unoconv: Cannot find a suitable office installation on your system.
ERROR: Please locate your office installation and send your feedback to:
http://github.com/dagwieers/unoconv/issues
bart@bit:
/src/unoconv$

Still the same output.

Kind regards

Bart

@bartbunting

This comment has been minimized.

Copy link

commented Feb 19, 2012

Hi Dag,

Is there anything further you require from me to debug this issue?

Kind regards

Bart

@dagwieers

This comment has been minimized.

Copy link
Member

commented Feb 19, 2012

I think it should work, did you try with the latest commits, including: bd9bec3 ?

Otherwise someone will have to understand what is going on, or I will have to find someone with a Mac :-/

@bartbunting

This comment has been minimized.

Copy link

commented Feb 19, 2012

Hi Dag,

I have tried with the latest version of master. Still no luck.

Is there a way to manually specify the paths? At least that way it may
show that if we find the correct path then everything works. Then it's
just a matter of fixing the detection?

Also, if it helps I could give you access to my laptop to have a go if
that is helpful?

Kind regards

Bart

@dagwieers

This comment has been minimized.

Copy link
Member

commented Feb 19, 2012

Sure, you can define the various paths just before they are being put in the structure in find_offices(). You can look at the class Office to understand the different arguments (path-names). Assigning values before putting them in an Office object will make unoconv use those. The normal way of setting the Office path is by setting UNO_PATH=/Applications/LibreOffice.app/Contents, but that is not the problem here, because unoconv is looking for some other stuff. (basepath, urepath, unopath, pyuno, binary, python, pythonhome)

I'd rather not access systems remotely.

@dlange

This comment has been minimized.

Copy link

commented Mar 2, 2012

I have the same problem, added my path "/Applications/OpenOffice.org.app/Contents/basis-link/program" to the extra paths, but am still getting the same error message. Has anyone been able to fix this?

@gloaec

This comment has been minimized.

Copy link

commented Mar 8, 2012

Having the same issue on MacOSX Lion with OpenOffice. Any fix yet ?

@gloaec

This comment has been minimized.

Copy link

commented Mar 8, 2012

  • "python" binaries (no ".bin") are located in "/Applications/OpenOffice.org.app/Contents/basis-link/share/Scripts"
  • "pyuno.so" -> "/Applications/OpenOffice.org.app/Contents/basis-link/program"
  • "soffice.bin" -> "/Applications/OpenOffice.org.app/Contents/program"

But still... Same error.

@gloaec

This comment has been minimized.

Copy link

commented Mar 8, 2012

Oops, "python" is a directory, my bad.

@gloaec

This comment has been minimized.

Copy link

commented Mar 8, 2012

Allright, seems to be a problem of architecture (x64), check this out :
$ python pythonloader.py
Traceback (most recent call last):
File "pythonloader.py", line 27, in
import uno
File "/Applications/OpenOffice.org.app/Contents/basis-link/program/uno.py", line 29, in
import pyuno
ImportError: dlopen(/Applications/OpenOffice.org.app/Contents/basis-link/program/pyuno.so, 2): no suitable image found. Did find:
/Applications/OpenOffice.org.app/Contents/basis-link/program/pyuno.so: mach-o, but wrong architecture

@dagwieers

This comment has been minimized.

Copy link
Member

commented Mar 12, 2012

It seems as if the python binary is incompatible with the pyuno.so python module. It's either not build using the same python version, or even a different architecture. So if your OpenOffice/LibreOffice does not ship with its own python binary, then I am afraid the installation is incomplete to make python UNO work.

It helps to know what version and provider these packages come from. I can highly recommend upstream builds so that any problems can be reported to upstream. It's not impossible that the bindings are broken in the upstream release.

@dagwieers

This comment has been minimized.

Copy link
Member

commented Apr 14, 2012

I am diverting this to milestone v0.6. I cannot postpone releases for stale issues. I need more feedback about where these installations come from, whether it works with other installations in MacOSX (are there any that ship with a python binary ?), ...

@bartbunting

This comment has been minimized.

Copy link

commented Apr 15, 2012

Sounds reasonable to me. I would ask that you keep it in mind though if
any further information comes up. I would very much like to get unoconv
working on my mac.

Kind regards

Bart

@dagwieers

This comment has been minimized.

Copy link
Member

commented Apr 15, 2012

I would like unoconv to work on Mac too, in fact I thought we had the support for it. So either I was wrong, it fails only for certain combinations of LibreOffice/OpenOffice/NeoOffice or we broke it along the way :-/

So I need feedback about the MacOSX version, the office version and anything that might influence a working unoconv (e.g. office location, python-version, etc...) The troubleshooting chapter in the README might be useful.

@kungla

This comment has been minimized.

Copy link

commented Apr 23, 2012

It would be wonderful if you fix it. I use this tool a lot and it works great under Ubuntu. OSX support would be nice

So I try to give any information you need:

Latest OSX Lion (10.7.3)
Latest LibreOffice 3.5.2.2

OSX built in Python version:

Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin

Error when running from 0.5 source :

unoconv: Cannot find a suitable pyuno library and python binary combination in /Applications/LibreOffice.app/Contents
ERROR: Please locate this library and send your feedback to:
       http://github.com/dagwieers/unoconv/issues
dlopen(/Applications/LibreOffice.app/Contents/program/pyuno.so, 2): no suitable image found.  Did find:
    /Applications/LibreOffice.app/Contents/program/pyuno.so: mach-o, but wrong architecture
unoconv: Cannot find a suitable office installation on your system.
ERROR: Please locate your office installation and send your feedback to:
       http://github.com/dagwieers/unoconv/issues

Also tried:
/Applications/LibreOffice.app/Contents/program/python -v -c 'import uno, unohelper'

# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/site.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/site.py
import site # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/site.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/os.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/os.py
import os # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/os.pyc
import errno # builtin
import posix # builtin
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/posixpath.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/posixpath.py
import posixpath # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/posixpath.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/stat.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/stat.py
import stat # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/stat.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/genericpath.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/genericpath.py
import genericpath # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/genericpath.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/warnings.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/warnings.py
import warnings # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/warnings.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/linecache.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/linecache.py
import linecache # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/linecache.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/types.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/types.py
import types # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/types.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/UserDict.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/UserDict.py
import UserDict # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/UserDict.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/_abcoll.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/_abcoll.py
import _abcoll # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/_abcoll.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/abc.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/abc.py
import abc # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/abc.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/copy_reg.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/copy_reg.py
import copy_reg # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/copy_reg.pyc
import encodings # directory /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/__init__.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/__init__.py
import encodings # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/__init__.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/codecs.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/codecs.py
import codecs # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/codecs.pyc
import _codecs # builtin
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/aliases.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/aliases.py
import encodings.aliases # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/aliases.pyc
# /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/utf_8.pyc matches /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/utf_8.py
import encodings.utf_8 # precompiled from /Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/lib/python2.6/encodings/utf_8.pyc
Python 2.6.1 (r261:67515, Mar 27 2012, 11:48:16) 
[GCC 4.0.1 (Apple Inc. build 5494)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
# uno.pyc matches uno.py
import uno # precompiled from uno.pyc
dlopen("./pyuno.so", 2);
Abort trap: 6

Anything else I can to do help?

@dagwieers

This comment has been minimized.

Copy link
Member

commented Apr 23, 2012

Thank you, this was very useful to exclude a few options.

Your first run specifically states: dlopen(/Applications/LibreOffice.app/Contents/program/pyuno.so, 2): no suitable image found. Did find: /Applications/LibreOffice.app/Contents/program/pyuno.so: mach-o, but wrong architecture

Which indicates the python that was used seems to mismatch the pyuno.so file.

The Abort trap: 6 looks weird too, if I google that I find: http://user.services.openoffice.org/en/forum/viewtopic.php?t=25388&p=205382 and https://issues.apache.org/ooo/show_bug.cgi?id=93084 reading that seems to indicate that there's a problem on MacOSX in general with OpenOffice, and maybe LibreOffice is affected from the same thing. The strange thing is that in this case the python used is the one that ships with LibreOffice (I assume, as I am not sure whether you are running a wrapper script, or the actual binary).

BTW An older issue #8 also mentioned Abort and has been closed waiting for feedback. Not sure if that helps in your case. We may need to bring this up on the LibreOffice mailinglist.

@dagwieers

This comment has been minimized.

Copy link
Member

commented Apr 23, 2012

Aha, the "mach-o, but wrong architecture" means that the library does not include your architecture and information on how to debug this is found in many posts (using Google), including: http://forums.macrumors.com/showthread.php?t=879780

I am more convinced this is a problem with the LibreOffice distribution.

@kungla

This comment has been minimized.

Copy link

commented Apr 24, 2012

Will you report this to LibreOffice team? - I would do this myself, but I don't have any python experience and it would be hard to explain things that I dont know so well.
Thanks for help.

@dagwieers

This comment has been minimized.

Copy link
Member

commented Apr 26, 2012

I have been thinking about this, but I am not going to open a bug report at http://bugs.freedesktop.org/ for this, someone that can reproduce this bug should do this as I have no means of providing feedback. Besides, I don't know what version of LibreOffice I need to report for, what type/version of MacOSX has this problem, etc... In fact I don't know a lot and I cannot persist to get this fixed.

So if someone wants to report it experiencing this problem, reproduce it with the latest LibreOffice (3.5.2 or 3.5.3RC1) head over to http://bugs.freesdesktop.org/, create a new bug for the LibreOffice product and describe the problem.

  • there is no python binary shipping with the LibreOffice product for MacOSX
  • the python binary that ships with (ypur version of) MacOSX is incompatible with the UNO python bindings shipping with LibreOffice
  • you get the error: dlopen(/Applications/LibreOffice.app/Contents/program/pyuno.so, 2): no suitable image found. Did find: /Applications/LibreOffice.app/Contents/program/pyuno.so: mach-o, but wrong architecture
  • it fails on both 3.4.6 and 3.5.2 (and 3.5.3RC1) -> please also verify this is the case :-)

Also mention this unoconv issue #27 so that they can check the information we already gathered about this problem.

@sfermigier

This comment has been minimized.

Copy link

commented May 16, 2012

I got unoconv working on MacOS Snow Leopard with LibreOffice 3.5.0.rc3.

I had to make the following changes (which probably break the script under other platforms):

--- a/unoconv
+++ b/unoconv
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/Applications/LibreOffice.app/Contents/program/python

 ### This program is free software; you can redistribute it and/or modify
 ### it under the terms of the GNU General Public License as published by
@@ -78,6 +78,7 @@ def find_offices():

         elif os.name in ( 'mac', ) or sys.platform in ( 'darwin', ):
             extrapaths += [ '/Applications/LibreOffice.app/Contents',
+                            '/Applications/LibreOffice.app/Contents/MacOS',
                             '/Applications/NeoOffice.app/Contents',
                             '/Applications/OpenOffice.org.app/Contents' ]

@@ -111,12 +112,10 @@ def find_offices():
                 basis = sub
                 info(3, "Found %s in %s" % (officelibrary, os.path.join(basepath, sub, 'program')))
                 break
-        else:
-            continue

         ### MacOSX have soffice binaries installed in MacOS subdirectory, not program
         program = 'error'
-        for sub in ('program', 'MacOS'):
+        for sub in ('MacOS', 'program'):
             if os.path.isfile(os.path.join(basepath, basis, sub, officebinary)):
                 program = os.path.join(basis, sub)
                 info(3, "Found %s in %s" % (officebinary, os.path.join(basepath, basis, sub)))

Here are the parameters that are sent to the Office class constructor:

('/Applications/LibreOffice.app/Contents', '/Applications/LibreOffice.app/Contents/error/error', '/Applications/LibreOffice.app/Contents/error/MacOS', '/Applications/LibreOffice.app/Contents/error/MacOS/pyuno.so', '/Applications/LibreOffice.app/Contents/MacOS/soffice.bin', '/Applications/LibreOffice.app/Contents/program/OOoPython.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/OOoPython', None)

Maybe if would be safer to hardcode this config (and others) instead of trying to guess ?

@kungla

This comment has been minimized.

Copy link

commented Jun 22, 2012

WOW. I can confirm it is working on Lion 10.7.4 and LibreOffice 3.5.4.2

As described on line 137 changed 'program' to 'MacOS' and used:
/Applications/LibreOffice.app/Contents/MacOS/OOoPython.framework/Versions/2.6/bin/python ./unoconv

Thank you!

@dagwieers

This comment has been minimized.

Copy link
Member

commented Jun 27, 2012

@lloeki That is quite interesting. Since unoconv is in fact mimicing the behavior of the python wrapper, I would prefer to see what needs to be modified in unoconv to behave exactly like the wrapper on MacOSX. The reason ? Because we have no influence over the wrapper itself. So I would appreciate it if you could verify if unoconv is doing all the items in the wrapper before kicking off python. Thanks for sharing your findings !

@scottprahl

This comment has been minimized.

Copy link

commented Jun 28, 2012

I also can confirm that the two changing 'program' to 'MacOS' and commenting out the DYLD_LIBRARY_PATH lines works with LibreOffice 3.5.4 and beta 3.6.0 under 10.7.4. There is lobbying to get the DYLD_LIBRARY_PATH lines commented out in 3.5.5 and in the release version of 3.6.0

It seems that 'program' to 'MacOS' should be changed in both lines 136 and 137

@scottprahl

This comment has been minimized.

Copy link

commented Jun 28, 2012

One final point. Distributions of LibreOffice before 3.5 have no chance of working under MacOS X because the necessary infrastructure is missing. It does not look like the distributions of MacOS X OpenOffice (3.4.0 or 3.4.1) have all needed parts. Specifically, 'pyuno.so', 'python' , and the OOoPython frameworks are missing.

@dagwieers

This comment has been minimized.

Copy link
Member

commented Jul 19, 2012

Can someone provide me with a patch that makes it work on MacOSX, without impacting Linux or Windows ? Unfortunately I am not considering modifying the python wrapper shipped by LibreOffice. My preference would be to mimic the wrapper's behavior and calling the python binary directly.

Since I cannot test it myself, and have already made various changes with limited success I am not going to go down that road again ;-)

@dagwieers

This comment has been minimized.

Copy link
Member

commented Jul 19, 2012

Ah, and since the v0.6 release is imminent (since we fixed a major cause for segfaults in LibreOffice) if someone is willing to look at this I will wait for a fix to arrive. If I receive no feedback, I might release v0.6 this weekend.

@scottprahl

This comment has been minimized.

Copy link

commented Jul 20, 2012

Great news! LibreOffice 3.6.0.1 has removed the troublesome DYLD_LIBRARY_PATH lines. Now if you change lines 136 and 137 so that 'program' becomes 'MacOS' , unoconv works without a problem with LibreOffice.

Unfortunately, BSD install differs from Linux install. Specifically, there is no -D option. There is a -d option, but it is incompatible with the -p option. Therefore, the only cross-platform way that I can see to modify the Makefile is to separate out the directory creation and the installation lines into two parts: first do 'mkdir -p' and then do 'install -p'

If you change lines 136 and 137 and modify the Makefile as described, then unoconv works immediately on MacOS if LibreOffice is installed. (It does not work with OpenOffice though).

@scottprahl

This comment has been minimized.

Copy link

commented Jul 20, 2012

All necessary changes to make unoconv work on MacOS are in https://github.com/scottprahl/unoconv.git

Download the latest LibreOffice 3.6.0.1 or later and install unoconv with 'make install' and everything works (at least under 10.7)

@scottprahl

This comment has been minimized.

Copy link

commented Jul 20, 2012

I forked unoconv and the necessary changes for MacOS can be found in

https://github.com/scottprahl/unoconv.git

@gloaec

This comment has been minimized.

Copy link

commented Jul 21, 2012

Thanks dude, this is a some very good news.

@gardners

This comment has been minimized.

Copy link

commented Jul 23, 2012

In case it is useful:

Replacing all instances of 'program' with 'MacOS' (i.e., quoted strings) and calling it via something like:
/Applications/LibreOffice.app/Contents/MacOS/OOoPython.framework/Versions/2.6/bin/python ./unoconv -vvv -e 02ex.html 02ex.doc

Works on OSX (provided the listener doesn't barf) with LibreOffice versions as shown below:

LibreOffice 3.5.2.2
Build ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f

OSX 10.7.3

Without those changes, I get the Abort Trap 6 that has been variously mentioned above.

@scottprahl

This comment has been minimized.

Copy link

commented Jul 23, 2012

Yep, that works because you're avoiding the script /Applications/LibreOffice.app/Contents/MacOS/python with its spurious definitions for DYLD_LIBRARY_PATH and calling LibreOffice's python directly. I wonder if it is worth the hassle of trying to support 3.5 when 3.6 has fixed the DYLD_LIBRARY_PATH issue.

It would be nice to sort out the listener issues, but at the moment these are resolved by re-running unoconv.

@gardners

This comment has been minimized.

Copy link

commented Jul 23, 2012

Hello,

On Mon, Jul 23, 2012 at 9:57 AM, scottprahl
reply@reply.github.com
wrote:

Yep, that works because you're avoiding the script /Applications/LibreOffice.app/Contents/MacOS/python with its spurious definitions for DYLD_LIBRARY_PATH and calling LibreOffice's python directly. I wonder if it is worth the hassle of trying to support 3.5 when 3.6 has fixed the DYLD_LIBRARY_PATH issue.

Well, I guess it depends how long until 3.6 is officially released for
Mac. When I just went to download the latest version for Mac, it only
offered 3.5.5.

It would be nice to sort out the listener issues, but at the moment these are resolved by re-running unoconv.

Indeed, and that is a fine solution for me.

Paul.

@scottprahl

This comment has been minimized.

Copy link

commented Jul 23, 2012

3.6.0.2 is available under the pre-release tab. It seems like it will be released generally on 30 July.

@lloeki

This comment has been minimized.

Copy link

commented Jul 23, 2012

IIUC the discussion on bugzilla regarding this issue, the fix will be in 3.5.6 anyway.

@gardners

This comment has been minimized.

Copy link

commented Jul 23, 2012

Super. In the meantime, I have a work around, so all is well.

Paul.

@scottprahl

This comment has been minimized.

Copy link

commented Sep 1, 2012

There remain two basic issues in unoconv that prevents the mainline from working 'out-of-the-box'

The first is the location of the pyuno binaries and the second is the use of "date --date " in the Makefile. These issues are fixed (in a hopefully cross-platform manner) in a fork https://github.com/scottprahl/unoconv.git that has been merged with the mainline 0.6 as of today.

EDIT: Mainline unoconv works fine now. I deleted my repository to avoid confusion.

@dagwieers

This comment has been minimized.

Copy link
Member

commented Sep 1, 2012

@scottprahl Is there an easy way to see a diff between your tree and my tree using Github ? Or is this only possible with a squashed pull-request ?

BTW I was wondering if the most simple solution to our problem is to normalize the path (this means replacing symlinks by real paths). I think this works best in all situations and requires no os-specific codepaths. I just commited a new patch that in fact normalizes all paths, the new function abspath() implements a combination of os.path.join() together with os.path.abspath().

Please all, report if this works or not on MacOSX !

@dagwieers

This comment has been minimized.

Copy link
Member

commented Sep 1, 2012

I am closing this bug as we (once again) assume it to be fixed by commit 00f7f97, if you experience any of the known issues above using the master branch on MacOSX, please reopen this ticket and add more details.

Also, if the current master branch does work for you (out of the box) we would like to know as well.

NOTE: Please use LibreOffice v3.5.6+ or LibreOffice v3.6.0+ as they contain necessary fixes.

@dagwieers dagwieers closed this Sep 1, 2012

@scottprahl

This comment has been minimized.

Copy link

commented Sep 2, 2012

Sorry, still no joy under MacOS :(

The Makefile works perfectly now.

I am currently trying to track down the symlink problem.

@scottprahl

This comment has been minimized.

Copy link

commented Sep 2, 2012

For what it is worth on MacOS, LibreOffice.app/Contents/program is a symlink to LibreOffice.app/Contents/MacOS (not the other way around). The problem boils down to the fact that launching soffice.bin via

prompt>  /Applications/LibreOffice.app/Contents/MacOS/soffice.bin 

works fine, but

prompt>  /Applications/LibreOffice.app/Contents/program/soffice.bin 

fails with

soffice.bin[18114:707] No Info.plist file in application bundle ...

I don't see another solution than using the /MacOS path directly.

@dagwieers dagwieers reopened this Sep 2, 2012

@dagwieers

This comment has been minimized.

Copy link
Member

commented Sep 2, 2012

The whole point of normalizing the path was to replace symlinks by its real path. I fixed it. Please try again :-/

@scottprahl

This comment has been minimized.

Copy link

commented Sep 2, 2012

Yep. Somehow I got an intermediate checkin that only had the abspath() function and not the realpath() function. It works fine now. No tweaks needed to the Makefile and the tests run perfectly. Nice work.

@dagwieers

This comment has been minimized.

Copy link
Member

commented Sep 2, 2012

@scottprahl Yes, my previous commit did not include the realpath() which was in fact what replaces the symlinks. I noticed after your comment that it was still broken. That's also why I renamed that function realpath() as that's what it was supposed to do so more obvious to future contributors.

So thanks specifically to your @scottprahl's care and persistence (and with the help of many others in this thread) we finally nailed it. We are ready to release v0.6 now !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.