Installation on Leopard broken? Error: The installed version of Xcode (3.1.4) is too old to use on the installed OS version. Version 14.2 or late is recommended

[barracuda156]

There is a report that Macports installation on 10.5.8 on a native PPC machine fails to build anything with the error:

Error: The installed version of Xcode (3.1.4) is too old to use on the installed OS version. Version 14.2 or late is recommended on MacOS.

I cannot personally verify this at the moment and therefore cannot help, since I am again temporarily away from PPC hardware.

Could someone confirm if everything works on Leopard?

For the reference, report is here: ​https://forums.macrumors.com/threads/macports-development-for-powerpc-10-4-10-5-10-6-unofficial-invitation-to-cooperate.2363509/page-2?post=31944841#post-31944841

[Traace]

Hi, I created this report over at the macrumors forum.

If you have any questions please ask :) Running a fresh 10.5.8 install with xcode 3.1.4 (including Unix tools)

And many thanks to barracuda156 for creating the report here.

[jmroot (Joshua Root)]

There's a version number printed at the end of that message. Version $rec or later is recommended on macOS ${macos_version_major}. If $macos_version_major is empty on your system for some reason, that will cause all kinds of problems.

No problems building things on Leopard in an x86 VM here BTW.

[barracuda156]

Replying to jmroot:

There's a version number printed at the end of that message. Version $rec or later is recommended on macOS ${macos_version_major}. If $macos_version_major is empty on your system for some reason, that will cause all kinds of problems.

No problems building things on Leopard in an x86 VM here BTW.

Where does macos_version_major get pulled from?

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

Where does macos_version_major get pulled from?

It's based on /usr/bin/sw_vers -productVersion. The code is here:

​https://github.com/macports/macports-base/blob/9c8da9d61008249ea51e130d7ea02cb2177799ad/src/macports1.0/macports.tcl#L760-L782

Can someone who experiences the problem please attach a main.log file? If sw_vers failed to run, the log should say so.

I might have seen this same error when trying to set up a PowerPC Leopard VM using QEMU a few months ago. I thought the problem was specific to the VM environment, since nobody else had reported it, and I didn't investigate further. I do have Leopard installed on a couple real PowerPC Macs that used to run MacPorts just fine; I could check if I now see the problem there too.

[ryandesign (Ryan Carsten Schmidt)]

My Power Mac G4 with Leopard hadn't been used in awhile but after selfupdating MacPorts from 2.3.x to 2.8.1 I seem to be able to upgrade ports normally, so if it's not working for you please attach a main.log showing the problem, and also check if /usr/bin/sw_vers -productVersion works (i.e. shows your OS version).

[barracuda156]

Replying to ryandesign:

My Power Mac G4 with Leopard hadn't been used in awhile but after selfupdating MacPorts from 2.3.x to 2.8.1 I seem to be able to upgrade ports normally, so if it's not working for you please attach a main.log showing the problem, and also check if /usr/bin/sw_vers -productVersion works (i.e. shows your OS version).

Thank you for checking. We need an update from Traace here, since I had not experienced the issue myself – however a) I do not recall if I upgraded to 2.8.0 on Leopard, and b) I got only one Leopard installation on a G5, so it is not very representative in any case.

[Traace]

Thanks for your help :)

/usr/bin/sw_vers -productVersion returns 10.5.8

This is the main.log from trying to build a newer version of text editor nano:

version:1
:debug:main Starting logging for nano @7.2_0
:debug:sysinfo Mac OS X  (darwin/9.8.0) arch powerpc
:debug:sysinfo MacPorts 2.8.0
:debug:sysinfo Xcode 3.1.4, CLT 1.0.0.9000000000.1.1192168948
:debug:sysinfo SDK 
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 
:debug:main Fetching nano-7.2_0.darwin_9.ppc.tbz2 archive size
:error:main The installed version of Xcode (3.1.4) is too old to use on the installed OS version. Version 14.1 or later is recommended on macOS .

[ryandesign (Ryan Carsten Schmidt)]

Replying to Traace:

I wonder why MACOSX_DEPLOYMENT_TARGET is empty

The default value of MACOSX_DEPLOYMENT_TARGET is based on the value of macos_version_major; if the latter isn't being determined properly of course the former won't be either.

​https://github.com/macports/macports-base/blob/9c8da9d61008249ea51e130d7ea02cb2177799ad/src/macports1.0/macports.tcl#L1219-L1225

What model Mac are you seeing this problem on, and does it have a working built-in Ethernet interface? My recollection now (this is from memory) is that my QEMU VM presented itself as a computer without built-in Ethernet, and an Ethernet card, but macOS uses the MAC address of the built-in Ethernet interface to compute the Mac's UUID. When it fails to find a built-in Ethernet interface, the message _CFGetHostUUIDString: unable to determine UUID for host. Error: 35 is printed by a whole lot of programs, including sw_vers, which was what was throwing MacPorts off in my case. I suspected MacPorts was trying to interpret that message along with the version output. While that one instance of the problem could be corrected, I suspected similar problems would affect other code in MacPorts or in ports' build systems so I didn't bother. The problem went away once I tricked macOS into thinking it had a built-in Ethernet interface.

[barracuda156]

Replying to Traace:

I wonder why MACOSX_DEPLOYMENT_TARGET is empty

Any update, is the issue resolved?

[jmroot (Joshua Root)]

In 9df79a09f8fff041d04046abcd6f6b56104069f9/macports-base (master):

Ignore stderr getting info from more external cmds

See: #66871