On 15 Feb., 22:02, Harry van der Wolf <[email protected]> wrote: > 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.
Are you sure this is still the case? I've done some superficial googling on the topic, and it looks to me as if there might be possibilities to compile wxWindows for x86_64. Have a look at http://wiki.wxwidgets.org/Development:_wxMac > My python 2.6 is both i386/x86_64 as most libraries/binaries/frameworks on > OSX. The difference sounds problematic. Does that actually mean that hugin and python are compiled to different standards? This might explain the 'mach-o, but wrong architecture' error. > 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. How can you tell the difference between the two? Really, cmake is a very capable build tool, and if it produces an .so as a SWIG module, I suspect it has good reason to do so - unless, of course, it's been ported sloppily to the Mac. On the other platforms, we rely on cmake to generate aptly named files, and manually interfering is generally not a good idea. The different extension might even reflect the 'mach- o but wrong architecture' error. Really, extensions shouldn't matter - it was just a wild shot in case they did, even though they shouldn't. > 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). Fine. So you've worked out working target directories for the Mac. / usr/local/lib and /usr/local/bin don't look like typical Python module paths to me - the modules may be found, since they are part of the system path, but usually Python also checks in directories like /usr/ local/lib/python2.6/dist-packages or /usr/local/lib/python2.6/site- packages for local python modules. It may be cleaner to use one of those, but for now, since we haven't even got the stuff to run yet, you might as well stick with what works for you. > I'll see how I can get it compiled as a .dylib. All other libs are .dylib > including libhugin_python_interface.dylib Thank you for your efforts. I hope it will work out eventually. Keep me updated on your progress! Kay -- 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
