Not working on Mac #27
Comments
|
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
assigned 
|
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. |
|
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 ! |
|
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 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? |
|
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:
Your case seems to:
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... |
|
Hi, Here are the contents of the directories in question: Maybe it gives a clew: bart@bit:/Applications/LibreOffice.app/Contents$ls -1 |
|
Can you send me the output of Thanks in advance ! |
|
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 ! |
|
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 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 |
|
Hi Dag, Sorry to say it appears not to have worked here :(. git log HEAD | head commit 09f97c8 Still the same output. Kind regards Bart |
|
Hi Dag, Is there anything further you require from me to debug this issue? Kind regards Bart |
|
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 :-/ |
|
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 Also, if it helps I could give you access to my laptop to have a go if Kind regards Bart |
|
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. |
|
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? |
|
Having the same issue on MacOSX Lion with OpenOffice. Any fix yet ? |
But still... Same error. |
|
Oops, "python" is a directory, my bad. |
|
Allright, seems to be a problem of architecture (x64), check this out : |
|
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. |
|
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 ?), ... |
|
Sounds reasonable to me. I would ask that you keep it in mind though if Kind regards Bart |
|
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. |
|
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) OSX built in Python version: Error when running from 0.5 source : Also tried: Anything else I can to do help? |
|
Thank you, this was very useful to exclude a few options. Your first run specifically states: Which indicates the python that was used seems to mismatch the pyuno.so file. The BTW An older issue #8 also mentioned |
|
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. |
|
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. |
|
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.
Also mention this unoconv issue #27 so that they can check the information we already gathered about this problem. |
|
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): 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 ? |
|
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: Thank you! |
|
@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 ! |
|
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 |
|
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. |
|
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 ;-) |
|
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. |
|
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). |
|
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) |
|
I forked unoconv and the necessary changes for MacOS can be found in |
|
Thanks dude, this is a some very good news. |
|
In case it is useful: Replacing all instances of 'program' with 'MacOS' (i.e., quoted strings) and calling it via something like: Works on OSX (provided the listener doesn't barf) with LibreOffice versions as shown below: LibreOffice 3.5.2.2 OSX 10.7.3 Without those changes, I get the Abort Trap 6 that has been variously mentioned above. |
|
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 |
|
Hello, On Mon, Jul 23, 2012 at 9:57 AM, scottprahl
Well, I guess it depends how long until 3.6 is officially released for
Indeed, and that is a fine solution for me. Paul. |
|
3.6.0.2 is available under the pre-release tab. It seems like it will be released generally on 30 July. |
|
IIUC the discussion on bugzilla regarding this issue, the fix will be in 3.5.6 anyway. |
|
Super. In the meantime, I have a work around, so all is well. Paul. |
|
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. |
|
@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 ! |
|
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. |
|
Sorry, still no joy under MacOS :( The Makefile works perfectly now. I am currently trying to track down the symlink problem. |
|
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 works fine, but fails with I don't see another solution than using the /MacOS path directly. |
|
The whole point of normalizing the path was to replace symlinks by its real path. I fixed it. Please try again :-/ |
|
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. |
|
@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 ! |
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
The text was updated successfully, but these errors were encountered: