On Jul 5, 2011, at 18:23, Joshua Root wrote: > On 2011-7-6 03:05 , Ryan Schmidt wrote: >> The "heads-up" here is going to be that if a port is going to use libtool, >> then libtool must be built using the same compiler being used to build the >> current port. (Otherwise you get the dreaded "unable to infer tagged >> configuration" error; search the issue tracker for many previous occurrences >> back when we switched the compiler from "gcc" to a specific gcc.) So, for >> example, users who have already had Xcode 4 on Snow Leopard will have a >> libtool built using gcc-4.2. Once they upgrade to MacPorts 2.0.0 they'll be >> using llvm-gcc-4.2, and anything they try to build using libtool will fail, >> until they rebuild libtool with llvm-gcc-4.2. >> >> To avoid such problems we could increase the revision of libtool after >> MacPorts 2.0.0 is released, to force a rebuild. But to ensure that users >> upgrade to MacPorts 2.0.0 first, the port would need to basically require >> MacPorts 2.0.0, and I'm not sure how to detect the MacPorts version from >> within a Portfile. > > So wait, does that mean that libtool can't be used by ports that have to > change configure.compiler for whatever reason?
I believe yes, it also means that. Similarly, using or not using ccache counts as part of the compiler. So if a user turns on or off the use of ccache in macports.conf, after already having built libtool with the other setting, they must rebuild libtool. https://trac.macports.org/ticket/27954 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
