Some recent MacPorts changes (using a different compiler based on the Xcode version, and distributing binaries) are causing problems for ports that use libtool (and other ports).
At build time, libtool records into itself the contents of the $CC variable. And the value of the $CC variable at libtool build time must be the same as the value of the $CC variable when you're actually using libtool; if it is not, you get the error "unable to infer tagged configuration". (Many prior occurrences of this error can be found in our issue tracker.) Previous instances where this problem occurred: * User installs libtool with MacPorts 1.5.0 or earlier, then upgrades to MacPorts 1.5.1, which introduced configure.cc and setting it to the absolute path to the compiler. * User installs libtool, then changes macports.conf to turn ccache on (or off). But now we have many more opportunities for this problem to arise: * User installs libtool on Snow Leopard with Xcode 4.0 or 4.1 with MacPorts 1.9, then upgrades to MacPorts 2 (which will set configure.cc to llvm-gcc-4.2 instead of gcc-4.2). * User installs libtool on Snow Leopard with Xcode 3.2 and MacPorts 2, then upgrades to Xcode 4 (same as above). * User installs libtool on Lion with Xcode 4.1 (configure.cc is llvm-gcc-4.2) and upgrades to Xcode 4.2 (configure.cc is clang). The solution in all these cases is to rebuild libtool so its notion of $CC is updated. There is also the case where the user installs any port that both uses libtool and changes its configure.compiler. There isn't a straightforward solution for that. Further problems arise if the compiler used on the buildbot is not the same compiler used on the user's machine, or if ccache is off on the builtbot but on on the user's machine (or vice versa). In this case the solution would be for the user to force a local build instead of using a fetched package. libtool is not the only port that records the value of $CC and other such variables into itself. Other examples include apr (which includes its own copy of libtool), fltk, mecab, wxWidgets (which include config scripts that other programs can ask for $CC and other values), hdf5-18 (which includes a wrapper script around cc)... I believe we should record not only the OS version into the registry and the archive name, but also the Xcode version, and if the Xcode version changes, force a rebuild of all ports, just like we do if the OS version changes. Another option is we could set libtool (and all other ports that encode $CC and such into themselves) to never fetch pre-built packages. That seems unfortunate though. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
