On Jul 22, 2010, at 04:20, Harry van der Wolf wrote:
> The resulted build, both hugin itself as the hugin dylibs, don't have the
> correct path when questioned with the "otool -L <bin or lib>". They do for
> the "external" libraries they are linked to like libjpeg etc.
> Both the binary and it's own libraries are "pathless" instead of mentioning
> "/opt/local/lib/<dylib>". It means that the binary can't find the libraries
> and the libraries can't find the other hugin libraries anymore.
> what options do I have:
> - Is there a Macports setting to enable/force this
> - Is there a MacPorts setting to run the install_name_tool (some post build
> option?)
> - should I use the libtool "-install_name" option
> - should I patch hugin, either directly of via the libtool option
>
> I can come up with a few other options but if MacPorts has a nice one that
> would be the preferred solution.
>
> (I did not have time yet to build a straight "no Macport" cmake build to see
> if that suffers from the same. It didn't in the past, but maybe I really have
> to patch the hugin CMakeList.txt files for the OSX builds before patching
> MacPorts).
If you're building with cmake, you should be using the cmake portgroup which
takes care of this for you. Add to the portfile beneath the "PortSystem 1.0"
line the line "PortGroup cmake 1.0". Then remove the things which this
portgroup takes care of for you, which are "depends_build port:cmake",
"configure.cmd cmake", "configure.pre_args", "configure.args
-DCMAKE_INSTALL_PREFIX:PATH=${prefix}". If you need to set additional
configure.args, be sure to use configure.args-append so you're not overwriting
the portgroup's configure.args.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
