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 _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-users
