Opened 3 years ago

Closed 2 years ago

#64607 closed submission (fixed)

fix for libtheora to build on 10.6.8 Rosetta

Reported by: barracuda156 Owned by: barracuda156
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: powerpc, snowleopard, rosetta Cc:
Port: libtheora

Description

libtheora fails to build for ppc on 10.6.8 Rosetta, however this simple fix works:

if {${os.major} == 10 && ${build_arch} eq "ppc"} {
configure.args-append --build=powerpc-apple-darwin10 \
                      --host=powerpc-apple-darwin10
   }

Attachments (3)

libtheora_patch_rosetta.diff (714 bytes) - added by barracuda156 3 years ago.
failure_on_10.6.8_main.log (121.3 KB) - added by barracuda156 3 years ago.
Log of errors, there are many
successful_build_after_fix_main.log (80.8 KB) - added by barracuda156 3 years ago.
Building successfully after the fix

Download all attachments as: .zip

Change History (14)

Changed 3 years ago by barracuda156

comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

In what way does it fail to build? It would be surprising to me if whatever failure you encountered uniquely only occurred on 10.6.8 when building for ppc. It seems more likely to me that it would occur on a broader range of systems: for example, perhaps it occurs any OS version when building for a non-default architecture. But I won't know without seeing your main.log.

comment:2 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

--build is supposed to reflect the machine doing the building while --host is supposed to reflect the machine on which the compiled program will ultimately run. As such, if you are building on an Intel Mac (as I assume you are based on the mention of Rosetta) then --build=powerpc-apple-darwin10 does not seem correct.

I also don't think your proposal correctly handles the universal variant. If this build system needs --build / --host flags, then it will most likely need different flags for each architecture in a universal build, which means using the muniversal portgroup. The muniversal portgroup already contains code that can set --build and --host flags for you, but regrettably only when the universal variant is selected; it is left up to the portfile author to set them correctly when the universal variant is not selected.

Changed 3 years ago by barracuda156

Attachment: failure_on_10.6.8_main.log added

Log of errors, there are many

Changed 3 years ago by barracuda156

Building successfully after the fix

comment:3 in reply to:  2 Changed 3 years ago by barracuda156

Replying to ryandesign:

--build is supposed to reflect the machine doing the building while --host is supposed to reflect the machine on which the compiled program will ultimately run. As such, if you are building on an Intel Mac (as I assume you are based on the mention of Rosetta) then --build=powerpc-apple-darwin10 does not seem correct.

It is correct because I build it natively as ppc32 using Rosetta.

Sergey-Fedorovs-Mac-mini:~ svacchanda$ port -v installed libtheora
The following ports are currently installed:
  libtheora @1.1.1_3 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2022-02-04T22:53:59+0800'

While many ports still do build for ppc on 10.6.8 with incorrect --build set for Intel, a number of ports fail with it. None has been failing so far because of --build=powerpc-apple-darwin10.

Last edited 3 years ago by barracuda156 (previous) (diff)

comment:4 Changed 3 years ago by kencu (Ken)

For MacPorts to accept a fix into either base or into a Portfile, it has to be what you would call a "pure, true fix". Anything else is, in the long run, going to be more trouble than it is worth.

You can see many many many examples all throughout the PRs and tickets and discussion lists from people who have found some workaround or another for their build or install problem that works for them on the machine they have in front of them.

No argument about that, and more power to them! They have something that works for them.

The problem comes when they want to share their proudly-discovered HACK with the world. Hacks like that almost always wind up being a big disaster in the end, once the build spreads to more systems, newer systems, other systems, etc. They cause a LOT of headaches.

I have been guilty of this myself at times, for sure. There are a number of HACK PRs in the PR queue now that will probably never be allowed into MacPorts, nor should they be.

So -- what you have found here works for you. That is great.

It will never be allowed into MacPorts like this, though, nor should it be.

That is great too!

Version 0, edited 3 years ago by kencu (Ken) (next)

comment:5 in reply to:  4 Changed 3 years ago by barracuda156

Replying to kencu:

For MacPorts to accept a fix into either base or into a Portfile, it generally has to be what you would call a "pure, true fix". Anything else is, in the long run, going to be more trouble than it is worth.

Sorry, could you please elaborate a bit? If I can improve it to make it more useful, I will. (I am aware that building on 10.6.8 for ppc is an exotic endeavor, but as long as it doesn’t interfere with anything else, why not add?)

Last edited 3 years ago by barracuda156 (previous) (diff)

comment:6 Changed 3 years ago by Wowfunhappy (Jonathan)

How are you actually running MacPorts under Rosetta? Are you just prefacing every command with /usr/bin/arch -arch ppc? I tried that, and it didn't seem like all subprocesses were actually going through Rosetta as I needed.

It would be nice if e.g. on Leopard, I could use Rosetta to create PPC binaries even though I don't have access to PPC hardware. This seems like something that should "just work" in theory.

comment:7 Changed 3 years ago by kencu (Ken)

I haven't tried it, Jonathan, but others have noticed that MacPorts follows the arch of the terminal.

SO it might happen that if you opened a terminal on 10.5 Intel in PPC arch, MacPorts would follow that. Some experimentation required, your mileage may vary, etc, etc.

comment:8 Changed 3 years ago by kencu (Ken)

You can build PPC software quite easily on 10.4 and 10.5 Intel, in general.

MacPorts has never enabled cross-arch building with gcc, because newer gcc versions don't support the easy "multi-arch" command line settings that make that simple, and building cross-arch otherwise requires quite a bit of shenanigans.

Some are working on this! See here:

https://github.com/iains/darwin-toolchains-start-here/discussions/13

comment:9 in reply to:  6 Changed 3 years ago by barracuda156

Replying to Wowfunhappy:

How are you actually running MacPorts under Rosetta? Are you just prefacing every command with /usr/bin/arch -arch ppc? I tried that, and it didn't seem like all subprocesses were actually going through Rosetta as I needed.

I have built Macports itself as ppc (passing --build=powerpc-apple-darwin10 and -arch ppc -m32 flags to configure) on 10.6.8 and set ppc as the build arch in Macports.conf. From what I see in Activity Monitor, most processes do in fact run as PowerPC. Some OS binaries lack ppc slices (say, ld and gnumake), but they support building for ppc.

So for example I have:

Sergey-Fedorovs-Mac-mini:~ svacchanda$ file /opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib 
/opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib: Mach-O dynamically linked shared library ppc
Sergey-Fedorovs-Mac-mini:~ svacchanda$ file /opt/local/libexec/macports/bin/tclsh8.5 
/opt/local/libexec/macports/bin/tclsh8.5: Mach-O executable ppc

Sergey-Fedorovs-Mac-mini:~ svacchanda$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.6.8
BuildVersion:	10K549
Last edited 3 years ago by barracuda156 (previous) (diff)

comment:10 Changed 2 years ago by barracuda156

In fact only --build=power-apple-darwin10 is enough for Rosetta to work: https://github.com/macports/macports-ports/pull/15580

comment:11 Changed 2 years ago by barracuda156

Owner: set to barracuda156
Resolution: fixed
Status: newclosed

In f70687997a022399a5f0f630086b3f3d4c1bc850/macports-ports (master):

libtheora: fix build on Rosetta
Fixes: #64607

Note: See TracTickets for help on using tickets.