On 16 Feb., 13:47, Harry van der Wolf <[email protected]> wrote:
> 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.
Let's hope we get it to work with 2.8.11 then.
> > > 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.
In the cmake documentation it says that you can pass compiler flags to
SWIG by:
SET_SOURCE_FILES_PROPERTIES( ${swig_generated_file_fullname}
PROPERTIES COMPILE_FLAGS "-bla")
Maybe that's where you can put in the flag to build a .dylib instead
of an .so
> > > 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.
> 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 suppose it's not an .so, but no dll either. I think on Windows they
have a .pyd extension, but you'd have to ask Thomas to be sure, since
he managed to get it to run on Windows.
> > 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 chose the one I'm using because it was in Python's module path
already. That way I had it out of the system path and still didn't
have to change anything to make Python find it.
> I'll try some more.
That's about the only good news on the topic today ;-)
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
