boost177 @1.77.0+universal: fails on arm64 Macs with -- "error: 64-bit PPC compilation is not supported when targeting OSX 10.6 or later"

[kithrup (Sean Eric Fagan)]

This seems to be the same as #63045, but I actually *do* need universal.

sudo port install boost177 -no_single -no_static        --->  Computing dependencies for boost177
--->  Fetching archive for boost177
--->  Attempting to fetch boost177-1.77.0_1+python310+universal.darwin_20.arm64-x86_64.tbz2 from https://packages.macports.org/boost177
--->  Attempting to fetch boost177-1.77.0_1+python310+universal.darwin_20.arm64-x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/boost177
--->  Attempting to fetch boost177-1.77.0_1+python310+universal.darwin_20.arm64-x86_64.tbz2 from https://kmq.jp.packages.macports.org/boost177
--->  Fetching distfiles for boost177
--->  Verifying checksums for boost177
--->  Extracting boost177
--->  Applying patches to boost177
--->  Configuring boost177
--->  Building boost177                                  
Error: Failed to build boost177: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_releas_ports_devel_boost177/boost177/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port boost177 failed

(I also tried it with no options; the only one that did anything was -universal.)

As far as I can tell, it... seems to be trying to compile PPC, although I have no idea why -- I changed macports.conf to have universal_archs arm64 x86_64.

I tried running the build command manually; the output of that is attached as "output.txt".

(I also tried uninstalling all of the ports and starting again. Same behaviour.)

[kithrup (Sean Eric Fagan)]

Output of attempting to manually build

[ryandesign (Ryan Schmidt)]

This seems to be the same as #63045, but I actually *do* need universal.

I see no similarity with #63045. The error in that ticket's log was:

error: No best alternative for libs/context/build/asm_sources

while the error in this ticket's log is:

error: 64-bit PPC compilation is not supported when targeting OSX 10.6 or later

[kithrup (Sean Eric Fagan)]

Hm, I wonder if I just misread it, or if I had the wrong one in the window. Sorry either way :(.

[jurgen-lentz (Jurgen Lentz)]

Any updates on this?

[kithrup (Sean Eric Fagan)]

Still not working. I plead for help. :)

[kencu (Ken)]

look at this file:

libs/thread/build/Jamfile.v2:273

and see why it is falling through to powerpc

[kithrup (Sean Eric Fagan)]

Replying to kencu:

libs/thread/build/Jamfile.v2:273

I'm not sure why you're saying that file. l have two files with that name and subpath, and around line 273 is

        result += <define>BOOST_THREAD_DONT_USE_CHRONO ;
        if ! [ configure.builds has_atomic_flag_lockfree 
            : $(properties) : "lockfree boost::atomic_flag" ]  {
           result += <library>/boost/atomic//boost_atomic ;                     
        }   

[kithrup (Sean Eric Fagan)]

Also, wow, I attached the wrong output.txt attachment. I'm just doing stupid for this.

[kithrup (Sean Eric Fagan)]

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost177/boost177/work/boost_1_77_0/tools/build/src/tools/darwin.jam however, has arch "combined" complaining if PPC is not supported:

        case combined :
        {
            if $(address-model) = 32_64 {
                if $(support-ppc64) {
                    options = -arch i386 -arch ppc -arch x86_64 -arch ppc64 ;
                } else {
                    # Build 3-way binary
                    options = -arch i386 -arch ppc -arch x86_64 ;
                }
            } else if $(address-model) = 64 {
                if $(support-ppc64) {
                    options = -arch x86_64 -arch ppc64 ;
                } else {
                    errors.user-error "64-bit PPC compilation is not supported w
hen targeting OSX 10.6 or later" ;
                }
            } else {
                options = -arch i386 -arch ppc ;
            }
        }

32-bits isn't supported any longer, so if ppc isn't supported, it should be x86_64 and arm64, no?

[kithrup (Sean Eric Fagan)]

I locally changed it to

            } else if $(address-model) = 64 {
                if $(support-ppc64) {
                    options = -arch x86_64 -arch ppc64 ;
                } else {
                    options = -arch x86_64 -arch arm64 ;
                }
            } else {

and it seems to have built & installed.

[kithrup (Sean Eric Fagan)]

Although it has installed itself into /opt/local/libexec/boost/1.77/lib when I would think it should have installed itself into /opt/local/lib, so did that patch do something weird?

[michaelld (Michael Dickens)]

That's the correct location for Boost installs ... each version installs into a different versioned subdirectory like that one, so that we can have multiple versions of Boost installed at the same time & then pick / choose from them which one gets used.

[kithrup (Sean Eric Fagan)]

Ok, whew. Not my introducing a bug then. :)

[kencu (Ken)]

Replying to kithrup:

Replying to kencu:

libs/thread/build/Jamfile.v2:273

I'm not sure why you're saying that file.

because the log said this:

808	:info:build Building the Boost C++ Libraries.
809	:info:build error: at libs/thread/build/Jamfile.v2:273
810	:info:build error: 64-bit PPC compilation is not supported when targeting OSX 10.6 or later

but it looks like you might have sorted something else out in the meantime :>

[kithrup (Sean Eric Fagan)]

Yeah, looks it complained there but the real problem was a few layers down from there.

[kithrup (Sean Eric Fagan)]

Do I need to do anything more for this? I don't know where that file is coming from, so I'm not sure how I could offer to fix it ;)>

[ryandesign (Ryan Schmidt)]

Has duplicate #65120 (for boost176).

[mascguy (Christopher Nielsen)]

It sounds like this has been resolved.

If you're still seeing an issue, let us know!

[kithrup (Sean Eric Fagan)]

Uh, how has this been resolved? I managed to fix a particular issue with it, locally, but there hasn't been any other change (that I'm aware of), and I have no idea how to fix it permanently.

[MrB74]

Same problem here. Building on M1 Mac Mini trying to get universal x64/arm64. Fails at the same location: :info:build error: at libs/thread/build/Jamfile.v2:273 :info:build error: 64-bit PPC compilation is not supported when targeting OSX 10.6 or later

[ASmoliak (Alex Smoliak)]

I can confirm that this problem occurs to me as well. It does look like a bug, the solution here is quite simple like you've done, however it does look like something that may not have anything to do with MacPorts, but rather than the boost developers themselves. I suggest opening an issue in Boost.Build. If you can't do that I'll do it for you.

[kithrup (Sean Eric Fagan)]

Thanks, I would greatly appreciate if you could do that!

[potterpg]

@kithrup I had the same issue, and was glad to find your answer.. @ASmoliak, will be good to get it fixed properly at the source of the problem.

[barracuda156]

Replying to kithrup:

32-bits isn't supported any longer, so if ppc isn't supported

PPC is supported (on darwin10 and earlier).

[kithrup (Sean Eric Fagan)]

And System 9 could support 68k. That's about as relevant.

[kencu (Ken)]

ppc is still actively supported by macports, also i386.

this old boost never considered an arch arm64 would come along and be a universal arch needing support. but now it has come anong.

someone needs to sit down with the code in darwin.jam and add support for arm64 as a universal arch, ideally without breaking everything else in the process.

[kencu (Ken)]

things have changed a bit it looks like in how this is being done, exactly…

​https://github.com/boostorg/build/blob/405d34a04d29519625c5edfe1f3bac3bc3dc3534/src/tools/darwin.jam#L514

[kencu (Ken)]

it’s more complicated, of course… macports is also altering darwin.jam in the Portfile.

​https://github.com/macports/macports-ports/blob/b81c2d73d57087e9aa01b61867ce1a3407e92759/devel/boost177/Portfile#L474

[mouse07410 (Mouse)]

I've a naive question: I understand perfectly why one wants to build for arm64, or for x86_64... I fail to understand why one would want "fat" aka "universal", rather than building a specific architecture-targeting binaries.

If it were up to me, I'd deprecate "universal" altogether.

[kencu (Ken)]

boost 176 universal fail log

[kencu (Ken)]

boost 176 (the default boost you get when you use sudo port -v install boost +universal does not build universal on an arm Mac:

displayed error is the same as above:

error: at libs/thread/build/Jamfile.v2:273
error: 64-bit PPC compilation is not supported when targeting OSX 10.6 or later

log attached.

I'll try building some newer boost and see if any of them can build universal.

[kencu (Ken)]

no, boost180 won't build universal either on this system:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/tools/build/src/build/feature.jam:491: in feature.validate-value-string from module feature
error: "combined" is not a known value of feature <architecture>
error: legal values: "x86" "ia64" "sparc" "power" "loongarch" "mips" "mips1" "mips2" "mips3" "mips4" "mips32" "mips32r2" "mips64" "parisc" "arm" "riscv" "s390x" "arm+x86"
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/tools/build/src/build/property.jam:337: in validate1 from module property
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/tools/build/src/build/property.jam:363: in property.validate from module property
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/tools/build/src/build/build-request.jam:286: in convert-command-line-element from module build-request
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/tools/build/src/build/build-request.jam:222: in build-request.convert-command-line-elements from module build-request
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/tools/build/src/build-system.jam:774: in load from module build-system
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/tools/build/src/kernel/modules.jam:294: in import from module modules
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/tools/build/src/kernel/bootstrap.jam:135: in module scope from module

Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0" && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost180/boost180/work/boost_1_80_0/b2 -d2 --layout=tagged --debug-configuration --user-config=user-config.jam -sBZIP2_INCLUDE=/opt/local/include -sBZIP2_LIBPATH=/opt/local/lib -sEXPAT_INCLUDE=/opt/local/include -sEXPAT_LIBPATH=/opt/local/lib -sZLIB_INCLUDE=/opt/local/include -sZLIB_LIBPATH=/opt/local/lib -sICU_PATH=/opt/local variant=release runtime-link=shared -j10 --no-cmake-config link=shared threading=multi pch=off address-model=64 architecture=combined 

[kencu (Ken)]

boost180 universal fails M1 Mac

[kaamui]

It seems that a workaround has been implemented in 1.81.0 => ​https://github.com/boostorg/build/commit/d312a161524213b7966eec440158f38fbaa497c2

Please note that poppler +universal fails to install too, because of boost176 dependency.

Still the same issue as with boost180 though