0

This is related to Git 2.4.8 built from kernel.org sources and missing HTTP/HTTPS helpers.

I found cURL's library was effectively configured with -arch ppc -arch ppc64, but the fat library that was built has the architectures -arch ppc7400 -arch ppc64. That's causing a Git configure/link failure, so Git's configure is [silently] dropping cURL, which is [silently] removing the HTTP/HTTPS helpers.

The really odd thing is the other eight or so dependent libraries are fine when built using the same steps. The dependent libraries have both -arch ppc -arch ppc64 as instructed. The other libraries include Zlib, Bzip, iConv, PCRE, and OpenSSL.

I've grepped the cURL sources with $ grep -IR -i "\-arch ppc7400" *, $ grep -IR -i "ppc7400" * and $ grep -IR -i "\-arch" *, but I cannot find the source of the change.

What can be the cause of the change from -arch ppc to -arch ppc7400?

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885

2 Answers2

3

This is not git- or curl-specific, and is in fact an intentional feature of the compiler. The compiler has noticed you are running on OS X 10.5 Leopard. ppc7400 is the architecture of the PowerPC G4 processor, which is the minimum processor required to run Leopard, so the compiler has changed your request for -arch ppc into -arch ppc7400 in order to generate the best code that will run on the minimum supported computer. If you want to support Macs running the earlier G3 processor, then that also means you'll need to support running on OS X 10.4, which is the last OS X version to support the G3. To do that, pass the -mmacosx-version-min=10.4 flag to the compiler, or set the MACOSX_DEPLOYMENT_TARGET environment variable to 10.4.

I've noticed that the translation from ppc to ppc7400 only happens if you are building universal (i.e. if you are also building for another architecture at the same time). I'm not sure why it doesn't do this when only building for a single arch.

ryandesign
  • 1,115
  • 6
  • 8
  • The *really* odd thing is the eight (or so) other dependent libraries build fine using the same steps. I don't understand why I'm only seeing the issue under cURL, and not Zlib, Bzip, iConv, PCRE, OpenSSL, etc... – jww Aug 29 '15 at 01:03
  • @jww most likely the build scripts for the working dependencies already have a lower `MACOSX_DEPLOYMENT_TARGET` set. – umläute Aug 31 '15 at 14:15
0

What can be the cause of the change from -arch ppc to -arch ppc7400?

Ryan was correct with respect to "... the compiler has changed your request for -arch ppc into -arch ppc7400 in order to generate the best code". Its documented at the GCC manual 3.17.10 Darwin Options.

However, some other statements in the answer were not quite on target, so I need to provide an answer to clear them up in case other people find the question and answer useful. First, the hardware is a Mac G5, not a G4.

Second, its not clear if the behavior is hard coded into the compiler or coming from a specs file.

Third, I experienced the issue from a standard ./configure && make; and not by calling out a universal or fat binary. I would have been happy if ./configure && make across all libraries and programs consistently produced code for either PPC, PPC970 or PPC7400. I switched to universal or fat binaries in an attempt to take total control of the situation.

Fourth, Mac G4's and OS X 10.4 have nothing to do with the issue.

Finally, the issue can be resolved easily enough without OS X SDK specific options by using:

export CFLAGS="-force_cpusubtype_ALL"

-force_cpusubtype_ALL may be needed in LDFLAGS, but it depends on how the library is using Autotools. For most of the libraries, it was sufficient to provide -force_cpusubtype_ALL in CFLAGS. PCRE was the exception to the rule.

jww
  • 97,681
  • 90
  • 411
  • 885