Hugin-app build fails because of old Mono.framework in /Library/Frameworks

[cjulien@…]

Hello, Please note that on a 10.5.8 Intel Black Macbook Hugin-app build fails. First things done were self update and port sync. Several dependencies also failed building but cleans and deactivate-reactivates fixed the problems.

Port invocation details

sudo port install hugin-app
Password:
--->  Computing dependencies for hugin-app
--->  Building hugin-app
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for hugin-app is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_hugin-app/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>
ZRB:~ zrb$

MacPorts Version is :

 > version
Version: 1.9.2

End of the log file (request for more)

:info:build ld warning: duplicate dylib /opt/local/lib/libboost_signals-mt.dylib
:info:build ld: file not found: /opt/local/lib/libjpeg.62.dylib
:info:build collect2: ld returned 1 exit status
:info:build make[2]: *** [src/hugin_base/libhuginbase.0.0.dylib] Error 1
:info:build make[1]: *** [src/hugin_base/CMakeFiles/huginbase.dir/all] Error 2
:info:build make: *** [all] Error 2
:info:build shell command " cd "/opt/local/var/macports/build/_opt_local_var_mac
ports_sources_rsync.macports.org_release_ports_graphics_hugin-app/work/hugin-201
0.4.0" && /usr/bin/make all " returned error 2
:error:build Target org.macports.build returned: shell command failed (see log f
or details)
:debug:build Backtrace: shell command failed (see log for details)
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: the following items did not execute (for hugin-app): org.ma
cports.activate org.macports.build org.macports.destroot org.macports.install
:notice:build Log for hugin-app is at: /opt/local/var/macports/logs/_opt_local_v
ar_macports_sources_rsync.macports.org_release_ports_graphics_hugin-app/main.log

[cjulien@…]

Cc Me!

[jmroot (Joshua Root)]

Definitely need to attach the full log. The important thing is where the reference to jpeg 6 is coming from.

[cjulien@…]

Huigin-app macports build log

[cjulien@…]

Does this log help a bit at troubleshooting the failed build ?

[hvdwolf@…]

MacPorts finds the libraries in the macports repository.

However, the hugin configure finds the tiff, jpeg and png headers in:

:info:configure -- Found TIFF: /Library/Frameworks/Mono.framework/Headers
:info:configure -- Found JPEG: /Library/Frameworks/Mono.framework/Headers
:info:configure -- Found PNG: /Library/Frameworks/Mono.framework/Headers

I don't have this Mono framework on my Snow Leopard, but I do have a /Library/Frameworks/Mono.Framework.tgz from March 2008. Is this Mono framework belonging to OSX verion 10.4, 10.5, 10.6?

I assume the Mono headers refer to a 6b.dylib that can't be found in /opt/local

[cjulien@…]

Thanks for the diagnostic !!

Sounds like it's due to my machine's history isn't it ? I don't know enough about configure to imagine a workaround that would have it to chose the right library.

Can anybody advice ?

Regards

[ryandesign (Ryan Carsten Schmidt)]

Remove /Library/Frameworks/Mono.framework*. It is not part of Mac OS X. You or some program you installed must've installed it at some point.

Something on your system has linked with the Mono.framework or its parts, from back when you did have it there. You'll need to identify those items, and rebuild them.

[jmroot (Joshua Root)]

The /usr/bin/pkg-config link that mono installs is probably the real problem.

[cooljeanius (Eric Gallager)]

This should be fixed now that #37341 has been fixed as of r101544 which sets CMAKE_FIND_FRAMEWORK=LAST in the cmake PortGroup to avoid these sorts of problems. Also newer versions of Mono.framework should no longer install /usr/bin/pkg-config any more.

[cooljeanius (Eric Gallager)]

Cc Me!

[mojca (Mojca Miklavec)]

Can this ticket be closed?

[ryandesign (Ryan Carsten Schmidt)]

Yes, let's assume this is fixed.