Opened 21 months ago

Last modified 14 months ago

#66871 new defect

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

Reported by: barracuda156 Owned by:
Priority: Normal Milestone:
Component: base Version: 2.8.1
Keywords: leopard, powerpc Cc: Traace
Port:

Description

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

Change History (10)

comment:1 Changed 21 months ago by 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.

comment:2 Changed 21 months ago by 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.

comment:3 in reply to:  2 ; Changed 21 months ago by 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?

comment:4 in reply to:  3 Changed 21 months ago by 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.

comment:5 Changed 21 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: Traace added

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

comment:6 in reply to:  5 Changed 21 months ago by 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.

comment:7 Changed 21 months ago by 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 .

I wonder why MACOSX_DEPLOYMENT_TARGET is empty

Last edited 21 months ago by Traace (previous) (diff)

comment:8 in reply to:  7 Changed 21 months ago by 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.

comment:9 in reply to:  7 Changed 20 months ago by barracuda156

Replying to Traace:

I wonder why MACOSX_DEPLOYMENT_TARGET is empty

Any update, is the issue resolved?

comment:10 Changed 14 months ago by jmroot (Joshua Root)

In 9df79a09f8fff041d04046abcd6f6b56104069f9/macports-base (master):

Ignore stderr getting info from more external cmds

See: #66871

Note: See TracTickets for help on using tickets.