Ryan Schmidt wrote:
what baffles me about this is that the libtool that's being invoked is part of the port's code:
/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -no-cpp-precomp -version-info 0:0:0 -L/opt/local/lib -lglib-2.0 -lintl -liconv -no-undefined -L/opt/local/lib -o libIDL-2.la -rpath /opt/local/lib parser.lo lexer.lo ns.lo util.lo
This is failing with 'unable to infer tagged configuration'? Seems pretty strange as it has a --tag argument, it should not even be trying to infer the tag.
if I run port configure (with -d), what's happening here?
configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by /usr/bin/g++-4.0... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the /usr/bin/g++-4.0 linker (/usr/bin/ld) supports shared libraries... yes
libtool is usually built in the build directory by running configure, it is included in the package. I had a quick look at the bugs mentioned:
http://trac.macosforge.org/projects/macports/ticket/13653 http://trac.macosforge.org/projects/macports/ticket/13648
In both cases an installed GNU libtool
which installed GNU libtool? you mean the libtool that the project built for itself?
one is calling /opt/local/bin/glibtool, the other is using apr's libtool (/opt/local/share/apr-1/build/libtool).
is being called with a different compiler (at least a different compiler name) than it was built with.
what compiler name was it built with, and what compiler name is it being called with? and why are they different?
I assume it was built with 'gcc' and it is being called with '/usr/bin/gcc-4.0'. Not the same name. Peter -- Peter O'Gorman http://pogma.com