2011/2/15 kfj <[email protected]> > On 14 Feb., 19:41, Harry van der Wolf <[email protected]> wrote: > > > cmake hadn't installed it. So I had to set the python path to the cmake > > build folder. > > You did the right thing for now. That is the current status quo on the > Mac. If you look at the CMakeLists.txt in the python_scripting > directory, you will see that the installation paths for, amongst other > things, Mac OS aren't set, because we didn't know what these paths > should be for python modules on Mac OS. This is where the Mac OS > wizards come in and set these paths to what they know to be > appropriate ;-) > > > I got the following error upon importing: > > ... > > ImportError: dlopen(./_hsi.so, 2): no suitable image found. Did find: > > ./_hsi.so: mach-o, but wrong architecture > > > > The "./_hsi.so: mach-o, but wrong architecture" is is a weird error. The > > _hsi.so is an i386 library like all the rest. > > This is indeed a weird error, but with this one I can't help you > beyond guesswork. Did you make an attempt to rename _hsi.so to what > you think is the accepted name for shared libraries, just on the off > chance that's the problem? And are you sure they're all either 32 bit > or 64 bit? > > Absolutely, that's exactly why I mention it as OSX is (AFAIK) the only platform where I can define for which architecture to build, without cross compiling.
> I've googled your error, and it seems to be a common thing, often > occuring when there are 32/64 bit problems. Often the tool lipo is > mentioned to have a look at the libraries in question. > > Yes, that's how I checked that everything is i386. > The next possibility is this: When importing a python module which has > been compiled from C or C++, if I'm not mistaken, the module should > ideally be compiled with the same compiler that the python interpreter > was compiled with. So if the python you have on your mac was compiled > with apple's compiler and your module is made by something else, > things might go wrong. Your Python interpreter says: > > [GCC 4.2.1 (Apple Inc. build 5664)] on darwin > > What gcc is being used to build hugin, and therefore the python > module? On my system gcc is 4.4.5, so maybe there's a problem here. It > may be enough to get a recent build of python, the best for > compatibilty's sake would be to compile pyhon from source with the > self-same compiler you're using otherwise. > > The gcc used is 4.2.1. The SDK used is 10.5 to be able to create i386 libs/binaries. I need to compile Hugin et al very strictly as i386 as the current wxwindows can't be compiled as x86_64 which is the default on Snow Leopard on intel. In my first attempt I didn't think of it and hugin et al were compiled as x86_64 and couldn't be linked against wxwindows. My python 2.6 is both i386/x86_64 as most libraries/binaries/frameworks on OSX. I renamed the .so to .dylib, but that doesn't make a difference, but I can't find where to change that it will be named a .dylib. I think that's also where the weird error comes from. When the system encounters an .so I assume it is expecting a "real" .so and not some incorrectly named .dylib. I removed the remarks in front of the install targets for the bottom ELSE(win32) in CMakeLists.txt and the _hsi.so got installed in /usr/local/lib which is correct. The hsi.py and hpi.py is also installed in /usr/local/lib where I think they should have been installed in /usr/local/bin (where the other .py files reside that I installed as a check). I'll see how I can get it compiled as a .dylib. All other libs are .dylib including libhugin_python_interface.dylib Harry -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
