2011/2/16 kfj <[email protected]>
> 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
>
That's the development version 2.9. We have issues and work-arounds already
for the stable 2.8.11 version (and previous). I have two separate
repositories on my macbook: a macports repository and a hugin repositories
with a huge load of redundant libs and so on and both have wxmac 2.8.11. I'm
not going to compile 2.9 right now.
>
> > 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.
>
No, it's not. That's exactly how OSX works. My bundles are i386/ppc/x86_64
architecture bundles. That's not 3 libraries or 3 binaries for each
architecture, but one library or binary containing all architectures.
You get used to that if you build for 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.
>
> 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.
>
>
As the tools tell that's is a mach-o library, it MUST be a dylib as that's
the OSX linker standard for building libraries. An .so is not a mach-o
library but generally an ELF library. If cmake/swig builds an .so for OSX
then it's doing something wrong. I assume that some header/meta data or
wahtever confuses the otool and lipo and link/loader tools.
I did some googling and I have seen .dylibs created from swig.
Does swig build an .so on windows or does it build a .dll?
> > 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 think it depends on the package. I also see
/usr/local/share/<package>/{lib,tool,contrib}.
I assume python gives you a lot of "freedom".
I'll try some more.
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
