hugin-app: missing dependency on libxslt

[thimo@…]

I've run "port install hugin-app" on my Snow Leopard machine and got the following message:

--->  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.

The error inside the log is:

:info:build ld: in /opt/local/lib/libxml2.2.dylib, file was built for unsupported file format which is not the architecture being linked (i386) for architecture i386
: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_macports_sources_rsync.macports.org_release_ports_graphics_hugin-app/work/hugin-2010.4.0" && /usr/bin/make all " returned error 2

The library file is

mymac /Users/thimo% file /opt/local/lib/libxml2.2.dylib
/opt/local/lib/libxml2.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64

and to my suprise the log shows that "-arch i386" is passed during the compilation.

My guess is that either hugin-app needs to depend on libxml2+universal (such that the 32bit version is always available) or cmake without +universal (to build in 64bit mode). As the usecase for hugin is to work on huge pictures I'd definitely prefer the latter.

[thimo@…]

Build log

[thimo@…]

Addenum: I've installed libxml2 +universal, now the linker complains about

:info:build ld: in /opt/local/lib/libxslt.1.dylib, file was built for unsupported file format which is not the architecture being linked (i386) for architecture i386
:info:build collect2: ld returned 1 exit status

Thus it is really a 32bit dependency problem (as expected).

[thimo@…]

Finally I've hacked the hugin-app Portfile to read:

supported_archs i386 ppc x86_64

which produces the error:

Error: Cannot install hugin-app for the arch(s) 'x86_64' because
Error: its dependency wxWidgets is only installed for the arch 'i386'
Error: and does not have a universal variant.
Error: Unable to execute port: architecture mismatch

Guess I've found the reason why only 32bit is supported... For wxWidgets the appropriate ticket seems to be #20952.

I suppose a mixed build (64bit worker binaries and 32bit viewer) isn't possible? If so, please only fix the dependencies to point to 32bit libraries.

[ryandesign (Ryan Carsten Schmidt)]

Seeing "-arch i386" in the hugin-app build should not surprise you. hugin-app must build 32-bit, because its dependency wxWidgets must build 32-bit. This requirement is enforced by the line "supported_archs i386 ppc" in both portfiles. When the default build_arch is x86_64 (as is the case on Snow Leopard), MacPorts will therefore compel all of hugin-app's declared dependencies to rebuild with the universal variant (i.e. for x86_64 and i386).

The problem here is that hugin-app doesn't actually declare a dependency on libxslt, hence MacPorts didn't know that it was supposed to rebuild it for you. And libxml2 only appears in the dependency chain as a runtime dependency of xorg-xcb-proto, hence MacPorts didn't know it was needed at build time. The solution is to add a library dependency on libxslt. (libxslt already has a library dependency on libxml2.) I'm testing this solution now and will report back.

[ryandesign (Ryan Carsten Schmidt)]

Actually I can find no evidence that hugin-app uses libxslt. (The string "xslt" does not appear anywhere in the hugin-app source.) Perhaps you have some other port installed (which uses libxslt) that hugin-app is finding and using. I'd like to compare your configure output with mine, but the log you've attached is not complete (contains lines "Skipping completed") and does not contain information about the configure phase. Could you please clean and try again, and attach the complete main.log?

sudo port clean hugin-app
sudo port install hugin-app

[thimo@…]

Sure. To (hopefully) reduced confusion I've reverted libxml2 (which was my original problem) to the old state, i.e. only installed as 64bit version.

[thimo@…]

Log after "clean"

[ryandesign (Ryan Carsten Schmidt)]

my log

[ryandesign (Ryan Carsten Schmidt)]

Thanks. I just don't know why this is happening. Your log looks the same as mine, up to the point where yours fails. I'm attaching my log in case someone else can find a relevant detail that I'm missing.

[hvdwolf@…]

Currently wxwidgets 2.8 is the default for Macports. Once 2.9 will be the default, which can be built as 64bit, we can also switch to 64bit hugin builds. Hugin as such supports 64bit builds and Universal builds. It only requires to remove the "supported_archs i386 ppc" and "universal_variant no" switch. (The soon to be released hugin 2011.0 will require some new dependencies though, but that will be taken care of at that time, but we will see what comes first)

The current dependency in the Portfile for Hugin is wxwidgets without version number. It might be possible, by means of a build switch, to change the portfile to use the 2.9 wxwidgets-devel port instead of the current wxwidgets-2.8 port. But I currently do lack the knowledge to change that and to also oversee the consequences (if any).

[ryandesign (Ryan Carsten Schmidt)]

Yes, but none of that addresses the fact that for the reporter, hugin-app is trying to use libxml2 and libxslt at build time, without such dependencies being declared.

[ryandesign (Ryan Carsten Schmidt)]

wxWidgets will not be updated to 2.9.x because 2.9.x is a development series. 3.0 is the next scheduled stable release of wxWidgets. See their ​roadmap.

[ryandesign (Ryan Carsten Schmidt)]

#14540 explains how to write a dependency that can be satisfied by either a stable port or a corresponding development port.

[mojca (Mojca Miklavec)]

Hugin-app is now depending on wxWidgets 2.9 (but fails to compile due to some boost craziness).

However: is there anything that can/should be done to close this ticket? It look to me like the title of this ticket should rather be "libxml2: missing dependency on libxslt" ;)

[mojca (Mojca Miklavec)]

But then again I saw #16110 and I noticed that libxstl depends on libxml2. I added the dependency on libxml2 to hugin-app, but the real problem is or was probably related to ticket #16110.

[mojca (Mojca Miklavec)]

Now that there are no more problems with wxWidgets and architectures - what should be done about this ticket? Can it be closed or should some dependencies be added first? (Before #41280 gets fixed I'm unable to test whether the port builds on the buildbots though.)

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

I added the dependency on libxml2 to hugin-app,

Why—did you find some way in which hugin-app was using libxml2? I could not. I'm inclined to revert that, and close this ticket as worksforme.

[mojca (Mojca Miklavec)]

I don't remember why, that's been a while ago, but it's also true that when I wrote that I was working with version 2011 or 2012, so things might have changed in the meantime (and maybe some library dependencies were dropped).

References to libxml2 include

./mac/ExternalPrograms/scripts/autopano-sift-C.sh:  -DLIBXML2_INCLUDE_DIR="/usr/include/libxml2" \
./mac/ExternalPrograms/scripts/autopano-sift-C.sh:  -DLIBXML2_LIBRARIES="/usr/lib/libxml2.dylib";
./mac/ExternalPrograms/scripts/panomatic-lib.sh:  -DLIBXML2_INCLUDE_DIR="/usr/include/libxml2" \
./mac/ExternalPrograms/scripts/panomatic-lib.sh:  -DLIBXML2_LIBRARIES="/usr/lib/libxml2.dylib" \
./mac/ExternalPrograms/scripts-legacy/autopano-sift-C.sh:  -DLIBXML2_INCLUDE_DIR="/usr/include/libxml2" \
./mac/ExternalPrograms/scripts-legacy/autopano-sift-C.sh:  -DLIBXML2_LIBRARIES="/usr/lib/libxml2.dylib";
./mac/ExternalPrograms/scripts-legacy/panomatic-lib.sh:  -DLIBXML2_INCLUDE_DIR="/usr/include/libxml2" \

but I'm not sure if any of those are actually being used. Feel free to revert my change and close the ticket if that's what you consider is the right fix. I really don't remember why I did what I did.

[mojca (Mojca Miklavec)]

Ryan, what do you suggest to do about this ticket?

[cooljeanius (Eric Gallager)]

Cc Me!