ffmpeg configure fails, clang unable to create executables

[ShadSterling (Shad Sterling)]

sudo port -p -N upgrade outdated updated many ports successfully, but fails to update ffmpeg

The reason in the logs appears to be :info:configure /usr/bin/clang is unable to create an executable file.

/usr/bin/clang --version says

Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

port output says configure failure but doesn't mention a config log (only the main log). I doubt /usr/bin/clang is actually unable to create an executable, but I don't see any indication of what the actual problem is. Trying with no variants and default variants had the same result

[ryandesign (Ryan Carsten Schmidt)]

Can you locate a config.log file anywhere within $(port work ffmpeg)? If so, please attach it.

[cjones051073 (Chris Jones)]

My bet is this is another issue caused by the issues in Xcode 15 with the new linker.

[kencu (Ken)]

It looks like you may have upgraded Xcode to 15, but not as yet upgraded the command line tools.

[ShadSterling (Shad Sterling)]

Yep, that was it. Apparently Xcode got updated automatically but the command line tools didn't, and when I got the message and ran the command to accept the license agreement it didn't warn me about the mismatch. Seems like something Apple could do better. After updating the command line tools it's working again. Thanks!

[ryandesign (Ryan Carsten Schmidt)]

The config.log said the error was:

ld: library not found for -ld_classic

[kencu (Ken)]

I'm sorry, I should let Ryan close this with the resolution he prefers, which may not be 'worksforme'.

[cjones051073 (Chris Jones)]

Replying to ryandesign:

The config.log said the error was:

ld: library not found for -ld_classic

That warning is a little misleading. It suggests the error is a missing library, which is not the case. It is just the ld version did not understand the ld_classic flag and mis-interpreted it as a library request.

[ryandesign (Ryan Carsten Schmidt)]

Right, there should probably be a ProblemHotlist entry explaining what it really means.

[ryandesign (Ryan Carsten Schmidt)]

I'm not planning on being the one to close this ticket because I'm not really involving myself in this set of issues. I would expect the ticket to remain open until it is fixed, or closed as a duplicate if there is another ticket tracking this set of issues. Although we recommend not having a mismatched set of Xcode and CLT, I don't understand why having a mismatched set caused this issue for this user. The user runs macOS 13, and we obviously never encountered this issue until after the release of macOS 14 and Xcode 15 since the -ld_classic flag was not something any version of the linker knew about until then, so the fact that this flag is getting inserted now on a system that doesn't understand it seems like a fixable bug to me.

[kencu (Ken)]

Chris, so this is twice now this issue shows up, where a user has Xcode 15 installed but also has out of date command line tools, so this error comes up when the -ld_classic flag is sent to the older ld in the CLTs that doesn't understand it.

I can't think of any good fix other than noticing the issue in their logs and telling people to update their CLTs, but Ryan is asking for one.

Can you think up some magic incantation to get past this issue?

[kencu (Ken)]

Actually "port diagnose" should be able to spot out-of-date CLTs, or mismatched CLTs and Xcode, and tell users to update them.

And MacPorts should require a "port diagnose" output with every ticket, and then we would never see these tickets at all, because "port diagnose" would have (should have) told people how to fix it before they submit the ticket.

[ShadSterling (Shad Sterling)]

port upgrade told me about one problem with the command line tools (that I had to accept the license agreement for them to work), it would have been helpful if it had told me to upgrade them in the same place

[cjones051073 (Chris Jones)]

Replying to kencu:

Chris, so this is twice now this issue shows up, where a user has Xcode 15 installed but also has out of date command line tools, so this error comes up when the -ld_classic flag is sent to the older ld in the CLTs that doesn't understand it.

I can't think of any good fix other than noticing the issue in their logs and telling people to update their CLTs, but Ryan is asking for one.

Can you think up some magic incantation to get past this issue?

I guess in principle it would be possible to query the CLT and xcode vesions, using something similar to what I do here

​https://github.com/macports/macports-ports/blob/master/lang/gcc13/Portfile#L174

to detect when to apply the flag in gcc builds.

It probably though would not make sense to do this at the port level, so its something someone would have to propose adding to base (perhaps adding it to port diagnose).

That though will take a long time to get to users, and by then who knows perhaps Apple would have fixed the issue anyway...

Until then, I think it is just a cause of being aware of this and looking out for it..

[cjones051073 (Chris Jones)]

Replying to kencu:

Actually "port diagnose" should be able to spot out-of-date CLTs, or mismatched CLTs and Xcode, and tell users to update them.

And MacPorts should require a "port diagnose" output with every ticket, and then we would never see these tickets at all, because "port diagnose" would have (should have) told people how to fix it before they submit the ticket.

Perhaps one way to do that is for port to automatically run 'diagnose' at the end ofa failed install, and just dump it into the end of the log...

[kencu (Ken)]

Replying to cjones051073:

Until then, I think it is just a cause of being aware of this and looking out for it..

Well, I agree -- working around mismatched Xcode and CLT installations is not a MacPorts bug to fix.

[mascguy (Christopher Nielsen)]

Replying to cjones051073:

Replying to kencu:

Actually "port diagnose" should be able to spot out-of-date CLTs, or mismatched CLTs and Xcode, and tell users to update them.

And MacPorts should require a "port diagnose" output with every ticket, and then we would never see these tickets at all, because "port diagnose" would have (should have) told people how to fix it before they submit the ticket.

Perhaps one way to do that is for port to automatically run 'diagnose' at the end of a failed install, and just dump it into the end of the log...

That sounds like an awesome idea, and would pay dividends for all sorts of issues going forward.

@jmroot, your thoughts on that?