trafshow 5.2.3_1 shouldn't use /usr/share/libtool

[ryandesign (Ryan Carsten Schmidt)]

trafshow 5.2.3_1 does not build when Xcode 2.5 is used on Tiger:

$ sudo port install
--->  Fetching trafshow
--->  Attempting to fetch trafshow-5.2.3.tgz from ftp://ftp.nsk.su/pub/RinetSoftware/
--->  Verifying checksum(s) for trafshow
--->  Extracting trafshow
--->  Applying patches to trafshow
--->  Configuring trafshow
Error: Target org.macports.configure returned: error copying "/usr/share/libtool/config.guess": no such file or directory
Error: Status 1 encountered during processing.
$

Xcode 2.5 no longer provides /usr/share/libtool so the solution is to use the MacPorts libtool port instead. The attached patch makes this change. Please let me know if I may commit this change to your port. Thanks.

[afb@…]

Shouldn't this be fixed for Xcode 2.5 instead ? It works fine with Xcode 2.4 or 3.0 or any other.

[ryandesign (Ryan Carsten Schmidt)]

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).

Anyway, I see this as another instance of this FAQ item:

​http://trac.macports.org/projects/macports/wiki/FAQ#WhyisMacPortsusingitsownlibraries

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.

There are less than a dozen ports at this point that used /usr/share/libtool. I am fixing the nomaintainer and openmaintainer ports now, and will file tickets for the others and will fix them as soon as their maintainers consent (or 72 hours after their nonresponse).

[afb@…]

Replying to 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#WhyisMacPortsusingitsownlibraries

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"...

[ryandesign (Ryan Carsten Schmidt)]

No response from maintainer in > 72 hours, so I committed the fix in r33304.

[(none)]

Milestone Port Bugs deleted