VLC @3.0.7.1_3+quartz: Fails to Build

[akierig (akierig)]

VLC @3.0.7.1_3+quartz fails to build after upgrading, log file attached. Darwin 18.7.0 Mac OS X.14.6

Attached log attempts to build with MP-Clang-8.0, I tried using MP-Clang-5.0 and MP-Clang-6.0 as suggested in ticket:58682, the error log is effectively identical.

[akierig (akierig)]

vlc_build_log_clang8

[RJVB (René Bertin)]

Which upgrade are we talking about here?

This looks to be the same error as #59123, could you do port edit VLC and add a line use_xcode yes somewhere?

[akierig (akierig)]

Good lord. I see now. Seems to have done the trick. Sorry for the duplication and thanks for your help!

[RJVB (René Bertin)]

You are welcome (and I not a lord ;) )

[akierig (akierig)]

I thought I should mention:

I had this problem yesterday on other ports (and on a Ruby Gem). The solution I found was to symlink MacOSX10.14.sdk>MacOSX.sdk in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/sdks

I'm just guessing that use_xcode yes is just telling it to use the generic MacOSX.sdk?

The most recent Xcode update seems to have screwed this up.

[RJVB (René Bertin)]

Apparently there's also a change to MacPorts "base" that introduces (and makes required) the use_xcode keyword.

I notice there are other issues with 10.14-dependent code that has been written without taking builds on earlier OS versions into account. The current one with avcapture.m (which I thought resolved) seems because of an attempt to backport a method declaration that doesn't even get used, instead of simply putting the bit of code where it is used in a #ifdef 10.14 conditional.

I'm beginning to get fed up with that kind (IMHO) arrogance that everyone always runs the latest OS...

[kencu (Ken)]

use_xcode yes was a response to many people who didn't want to have to install a full Xcode to use MacPorts, but wanted to install the command line tools only. Many ports don't need a full Xcode installation -- but some that use Xcode-specific tools, do. You can opine about whether this request for no full Xcode should have been supported -- but in the end, it was.

And that means that ports that do need a full xcode installation now have to specifically say so. Democracy -- has it's downsides :>

Regarding 10.14 specific code, you will see me and others regularly try to make sure the older systems, all the way back to 10.4 Tiger, are as supported as possible. Any help you or anyone else would care to offer in doing that is most graciously accepted. So long as it doesn't break newer systems, and is not overly cumbersome or unintelligible, the MacPorts admins have indicated they will continue to accept it with thanks.

[kencu (Ken)]

In response to Apple's removing /usr/include from the default installation path in Mojave, MacPorts' builds were forced to specifically include building against an SDK in most cases. The following tool was most often used to find the SDK:

xcrun --show-sdk-path

And (unfortunately perhaps) this delivers a fully-versioned SDK path, rather than a generic one. This path was baked into a number of build scrips that were installed with various ports.

But then Xcode11 removed MacOSX10.14.sdk and replaced it with MacOSX10.15.sdk.

So now we realize that the method used was too fragile, and we are currently struggling to come up with a more robust, less fragile version of the method to accomplish the goal of finding the right SDK.

I personally think that setting SDKROOT in the environment is the right answer, and that is now in base, but this is being worked through all the different systems and ports that need to use it.

It's a tricky problem.

[RJVB (René Bertin)]

Replying to kencu:

And that means that ports that do need a full xcode installation now have to specifically say so. Democracy -- has it's downsides :>

According to Heinlein it's a nice experiment that cannot work (or is bound to fail - Glory Road).

Anyway, I would probably have done the opposite implementation, defaulting to expecting a full Xcode install and let ports that don't need it declare that. I realise that might not be trivial to implement. Or something that sets 'use_xcode=yes' when it a full and activated Xcode is detected. What I don't get is exactly what is different here. I had full Xcode installs before installing MacPorts so never discovered whether or not it was a requirement. It strikes me as extremely odd that a port that needs to use tools like ibtool fails if they are available because Xcode is installed.

[RJVB (René Bertin)]

Replying to kencu:

In response to Apple's removing /usr/include from the default installation path in Mojave

WTH??? And we're still dealing with a certified Unix?

Is there no way to bring back this directory, next to or just under $prefix/include and with injection of -isystem $prefix/whatever into the compiler flags?

I'm all for trying to support older OS versions, and less and less inclined to jump through hoops to support the modern abominations ...

[kencu (Ken)]

Throw into this mixture the fact that a new MacPorts' version just rolled out, a new Xcode was just released, and -- just for fun -- gcc can't yet build against the MacOSX10.15.sdk so everything related to gcc is just plain broken in Xcode 11 (unless you go through hoops to install and use the MacOSX10.14.sdk) -- and you get the current flurry of tickets, all pretty much about the same things.

[kencu (Ken)]

And Catalina is just around the bend. So get ready :>

[kencu (Ken)]

Replying to RJVB:

Is there no way to bring back this directory, next to or just under $prefix/include and with injection of -isystem $prefix/whatever into the compiler flags?

Yes, well that is more or less exactly what we are doing, but using the equivalent:

-isysroot `xcrun --show-sdk-path`

which sounded too good to be true, and -- in the end -- was.

[RJVB (René Bertin)]

Reminds me ... the other day I learned that Visual Studio is now available on Mac too (nudge nudge, hint hint) ;)