#13993: trafshow 5.2.3_1 shouldn't use /usr/share/libtool --------------------------------------+------------------------------------- Reporter: ryandesign@macports.org | Owner: ryandesign@macports.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: | Keywords: --------------------------------------+------------------------------------- Comment (by afb@macports.org): Replying to [comment:2 ryandesign@macports.org]:
I thought that Xcode 2.5 deliberately does not install these items so as not to conflict with the same items which would be installed by Xcode 3.0, in the case where Xcode 2.5 and Xcode 3.0 are installed on the same system (which is possible on Leopard).
Sure, but it's a bug that it doesn't install it on Tiger... (as it should include the software installs in /usr there) As stated, it works fine with Xcode 2.4 or Xcode 3.0 ? To me, it is "Xcode 2.5 is not recommended on Tiger".
Anyway, I see this as another instance of this FAQ item:
http://trac.macports.org/projects/macports/wiki/FAQ#WhyisMacPortsusingitsown...
MacPorts should use its own software, not Apple software, wherever
possible, because Apple can (and in this case, for our purposes, did) break their software from time to time. Regardless of whether it's a bug in Xcode 3.0 or an intended feature, it currently breaks our ports, therefore we need to fix our ports. Sure, but MacPorts is a little lax about using its own versions of libtool and make and gcc and a lot of other things "normally" provided by Xcode Tools. So every now and then, something like this happens. Had the policy said "we only use Xcode" or "we provide everything ourselves", it would be easier to troubleshoot than the current "we use some things from Xcode and some from MacPorts" random selection. But I'm sure noone objects to this little port requiring "libtool"... -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/13993#comment:3> MacPorts </projects/macports> Ports system for Mac OS