harfbuzz @10.1.0_2+universal: ninja: error: unknown target 'CFLAGS+=-arch x86_64'

[thetrial (alabay)]

This morning I could upgrade harfbuzz to 10.1.0_1 n the other machine … but on this one I rund and run after. I could not upgrade pango, I made a rev-bump, then a reclaim and wanted to start off … and now harfbuzz hangs again?!

I don’t understand anymore if harfbuzz, ninja, mesa or pango is the problem. Guess it is +universal. Thanks dead wine.

I’ll attach the logfile. Just outta #71508 into this one.

[mascguy (Christopher Nielsen)]

Can you run sudo port diagnose, and paste the output?

[thetrial (alabay)]

Warning: found dylibs in your /usr/local/lib directory. These are known to cause problems. We'd recommend you remove them.

There is only a SUVMMFaker.dylib, I guess it shouln’t interfere.

BTW, on the other machine (that went through, though not with this newest harfbuzz now) there are quite more things (libosxfuse stuff).

[ryandesign (Ryan Carsten Schmidt)]

The log says the problem is:

ninja: error: unknown target 'CFLAGS+=-arch x86_64'

so what you have in /usr/local is irrelevant for now.

I think this arg is being added here:

​https://github.com/macports/macports-ports/blob/1eef4efee705c038c2f00888965da832a77b247b/_resources/port1.0/group/gobject_introspection-1.0.tcl#L111-L112

[psiborg112 (Aaron Wyatt)]

I'm seeing the exact same issue. The only thing that's changed since the last time I built it and now is that there's been an update to the meson port. (And I stupidly removed the old inactive version, so I can't put that theory to the test.)

[psiborg112 (Aaron Wyatt)]

Replying to ryandesign:

The log says the problem is:

ninja: error: unknown target 'CFLAGS+=-arch x86_64'

so what you have in /usr/local is irrelevant for now.

I think this arg is being added here:

​https://github.com/macports/macports-ports/blob/1eef4efee705c038c2f00888965da832a77b247b/_resources/port1.0/group/gobject_introspection-1.0.tcl#L111-L112

Seems weird that that would be causing a problem now given it worked very recently, and the foreach tool {cc ld} line that encapsulates it suggests it shouldn't be added to a ninja command. I'll keep digging when I get a chance. I really suspect meson is doing something strange here, but I could be wrong.

[ryandesign (Ryan Carsten Schmidt)]

Replying to psiborg112:

The only thing that's changed since the last time I built it and now is that there's been an update to the meson port.

Are you sure that's all that changed? This was almost certainly caused when gobject introspection was enabled in harfbuzz a few hours before this ticket was filed which was needed to fix another bug.

[psiborg112 (Aaron Wyatt)]

But that change worked when I edited the portfile manually to include both muniversal and gobject-introspection previously. It's what the fix was based on. And it doesn't seem like anything else was changed beyond that in the portfile? (Unless I'm missing something and there was more altered in the patch to it?)

[psiborg112 (Aaron Wyatt)]

Scratch that. It seems like there was a second commit after those two lines were added which has made some additional changes which I haven't tested. I'm going to try reverting some of those.

[psiborg112 (Aaron Wyatt)]

Ok, commit 6f8258f fixed the universal builds issue and then 16a59ac broke it again. Reverting the changes in that patch fixes the issue, but it might not be the 'right way' to deal with gobject_introspection.

[ryandesign (Ryan Carsten Schmidt)]

Replying to psiborg112:

and the foreach tool {cc ld} line that encapsulates it suggests it shouldn't be added to a ninja command.

You're misreading the code. The code says for each tool, map the tool name to an environment variable name (e.g. it maps cc to CFLAGS and ld to LDFLAGS). Then it appends CFLAGS+=-arch … and LDFLAGS+=-arch … to the separate build.args.… variables for each architecture. These args would presumably be understood if the build.cmd were make but ninja doesn't seem to understand it. The rudimentary support for meson added to the gobject_introspection portgroup may need further enhancement.

[psiborg112 (Aaron Wyatt)]

Replying to ryandesign:

Replying to psiborg112:

and the foreach tool {cc ld} line that encapsulates it suggests it shouldn't be added to a ninja command.

You're misreading the code. The code says for each tool, map the tool name to an environment variable name (e.g. it maps cc to CFLAGS and ld to LDFLAGS). Then it appends CFLAGS+=-arch … and LDFLAGS+=-arch … to the separate build.args.… variables for each architecture. These args would presumably be understood if the build.cmd were make but ninja doesn't seem to understand it. The rudimentary support for meson added to the gobject_introspection portgroup may need further enhancement.

Thanks for the clarification. (Sorry, totally new to dealing with portfiles and the inner workings of macports.)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #71784.

[kencu (Ken)]

has (yet another) duplicate #71925

[cgilles (HumanDynamo)]

I can reproduce the dysfunction today from a fresh macports install

[Lord-Kamina (Gregorio Litenstein)]

Log output from a fresh macports install on Github Actions

[Lord-Kamina (Gregorio Litenstein)]

I'm having the same issue, trying to install harfbuzz +universal as a dependency for ffmpeg7 +universal.

ETA: Have attached some logs as well.

[Lord-Kamina (Gregorio Litenstein)]

Are PortGroups processed sequentially in a Portfile? If so, I think a solution (haven't tested) might be to swap the meson and gobject_introspection lines, because the latter checks for the former but it wouldn't yet have been set if it works this way.

[Lord-Kamina (Gregorio Litenstein)]

patch portgroup so it checks if building with meson.

[Lord-Kamina (Gregorio Litenstein)]

main.log after changing the Portgroup and making sure PG meson comes before PG gobject_introspection

[Lord-Kamina (Gregorio Litenstein)]

That didn't work... I had read it wrong, it checks for meson somewhere else in the portgroup.

I tried that change anyway (making sure PortGroup meson 1.0 comes before PortGroup gobject_introspection 1.0, but I also changed the gobject_introspection PG to check if the port was using ninja. Doing this, it still failed but it began building and exploded during linking instead, seemingly because it couldn't properly keep both architectures apart properly.

Check the attached patch and log file.

[Lord-Kamina (Gregorio Litenstein)]

I have also noticed that muniversal-1.1 seems to have a bug (although I'm not if that's actually the cause of the issue here) in the determining of the _FOR_BUILD set of variables.

:debug:configure Environment: 
:debug:configure ARCHPREFERENCE='x86_64'
:debug:configure CC='/usr/bin/clang'
:debug:configure CC_FOR_BUILD='/usr/bin/clang'
:debug:configure CC_PRINT_OPTIONS='YES'
:debug:configure CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_custom_portfiles_graphics_harfbuzz/harfbuzz/work/.CC_PRINT_OPTIONS'
:debug:configure CFLAGS='-pipe -Os -DHB_NO_PRAGMA_GCC_DIAGNOSTIC_ERROR -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch x86_64'
:debug:configure CFLAGS_FOR_BUILD='-Os -DHB_NO_PRAGMA_GCC_DIAGNOSTIC_ERROR -arch arm64'

[Sabine-Schnabeltier (Sabine Schnabeltier)]

I've encountered this problem as well when trying to install a universal Cairo. The problem is that gobject_introspection is adding the environment variables to the ninja arguments rather than to the environment as was done with muniversal PG 1.0.

:debug:build system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_harfbuzz/harfbuzz/work/build-arm64" && /opt/local/bin/ninja -j8 CFLAGS+="-arch arm64" LDFLAGS+="-arch arm64" -v 
:info:build ninja: error: unknown target 'CFLAGS+=-arch arm64'

I took a stab at modifying gobject_introspection by replacing:

                    build.args.${arch}-append ${env_var}+="[muniversal::get_archflag ${tool} ${arch}]"

with:

                    lappend merger_build_args(${arch}) ${env_var}+="[muniversal::get_archflag ${tool} ${arch}]"

which allowed harfbuzz to compile, but something is going wrong during link.

[TellowKrinkle]

Replying to Sabine-Schnabeltier:

which allowed harfbuzz to compile, but something is going wrong during link.

The muniversal 1.0 code is also adding to build args (merger_build_args), the only reason it acts differently is the 1.0 code's method of adding arguments doesn't work on 1.1 so it's doing nothing. The link failure is the issue the code is trying to fix.

You can set environment variables like this (note the lack of quotes):

build.env.${arch}-append ${env_var}=[muniversal::get_archflag ${tool} ${arch}]

Which does work, but unlike the make arguments, this will override any build cflags/ldflags set elsewhere in the portfile, so it's not ideal.

[Sabine-Schnabeltier (Sabine Schnabeltier)]

Replying to TellowKrinkle:

Thank you, it works perfectly!

Do you think you could post this fix to GitHub?

[tellowkrinkle (TellowKrinkle)]

In a02018a6e5c03ac203c39416c517a33c4e422aaa/macports-ports (master):

gobject_introspection: Fix meson universal builds

Closes: #71699