Building Clang 8/9 in El Capitan

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Building Clang 8/9 in El Capitan

Christian Calderon
Hello MacPorts Users!

I’m trying to build Clang in El Capitan 10.11.6. The machine is an 8 core 2008 Mac Pro with 64GB of RAM, and I’ve got Xcode 7.3 and the corresponding Command Line Tools installed, as well as the latest version of MacPorts.

When I tried building the port clang-9.0, the build failed because the clang provided by Apple in Xcode 7.3 doesn’t support thread local storage. So I figured I’d try building clang-8.0 and then I could specify to MacPorts to use that compiler to build clang-9.0.

But building clang-8.0 failed as well. This time there isn’t a helpful error message, it just fails at 89% through.

I know that Xcode 8 has a newer version of clang but I don’t want to install it because it lacks the 10.11 SDK which some ports require.

Has anyone run into this problem before?

~ Christian Calderon

Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

Ken Cunningham
Both clang-8.0 and clang-9.0 having been building properly for us on the buildbots and (when I last did it) locally for me, on ElCap.

See <https://ports.macports.org/port/clang-9.0/summary> and the one for clang-8.0.

But your logic is flawed about why you want it, as no clang version provides a macOS SDK, those come with either XCode or the Command Line Tools which you install separately from Apple.

If you have a build error with clang 8 or 9, open a ticket and include your log, and we'll what might be wrong.

Bes;t

Ken
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

Christian Calderon
Hi Ken,
Thanks for the reply. I think I've miscommunicated something here so I'm going to try explaining my goals better. Ultimately, I'm trying to install PyCUDA. PyCUDA's build process wants to know which compilers are used to build some of its dependencies. One of the dependencies is Numpy and another is Boost.

I initially had my MacPorts install configured to build ports only if needed, but I realized I didn't know which compiler was used to build the ports I was downloading. So I figured that If I configured MacPorts to always build every port, then I would be able to easily see which compiler was used. I ran into a problem with Numpy though. Numpy depends on OpenBLAS, and OpenBLAS requires gcc to build. By default OpenBLAS will try to use gcc10 to build, and gcc10 wants to be built with clang-9.0. OpenBLAS has variants for using other versions of gcc to build, one for gcc9, gcc8, gcc7, gcc6, etc. The problem I am having is that it seems each of the gcc versions that OpenBLAS can be built with ultimately have a runtime dependency on libgcc10, which wants to be built with clang-9.0.

Building clang-9.0 fails because the clang supplied by Xcode 7.3 doesn't support thread local storage. I could fix this by installing Xcode 8.2, which is the last version that runs on El Capitan. Xcode 8.2 comes with a newer version of clang which does support thread local storage, and that should be able to build clang-9.0.

My issue with this solution is that updating Xcode from 7.3 to 8.2 will delete the older 10.11 SDK and replace it with the 10.12 SDK. I use other ports which will not build if the correct SDK is not found, the first one that comes to mind is mit-scheme. Many times in the past I've had issues building it after upgrading Xcode for this reason.

The only thing I can think of to fix this mess is to save a copy of the 10.11 SDK and then put it back after upgrading Xcode. Is that correct?

~ Christian Calderon

On Fri, Feb 12, 2021 at 7:20 AM Ken Cunningham <[hidden email]> wrote:
Both clang-8.0 and clang-9.0 having been building properly for us on the buildbots and (when I last did it) locally for me, on ElCap.

See <https://ports.macports.org/port/clang-9.0/summary> and the one for clang-8.0.

But your logic is flawed about why you want it, as no clang version provides a macOS SDK, those come with either XCode or the Command Line Tools which you install separately from Apple.

If you have a build error with clang 8 or 9, open a ticket and include your log, and we'll what might be wrong.

Bes;t

Ken
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

ryandesign2
Administrator


On Feb 12, 2021, at 10:11, Christian Calderon wrote:

> Thanks for the reply. I think I've miscommunicated something here so I'm going to try explaining my goals better. Ultimately, I'm trying to install PyCUDA. PyCUDA's build process wants to know which compilers are used to build some of its dependencies. One of the dependencies is Numpy and another is Boost.
>
> I initially had my MacPorts install configured to build ports only if needed, but I realized I didn't know which compiler was used to build the ports I was downloading.

That's true. MacPorts is not designed to provide you with this information. Nobody's ever asked for it before and I'm not sure I see why you would need to know.


> So I figured that If I configured MacPorts to always build every port, then I would be able to easily see which compiler was used. I ran into a problem with Numpy though. Numpy depends on OpenBLAS, and OpenBLAS requires gcc to build. By default OpenBLAS will try to use gcc10 to build, and gcc10 wants to be built with clang-9.0. OpenBLAS has variants for using other versions of gcc to build, one for gcc9, gcc8, gcc7, gcc6, etc. The problem I am having is that it seems each of the gcc versions that OpenBLAS can be built with ultimately have a runtime dependency on libgcc10, which wants to be built with clang-9.0.
>
> Building clang-9.0 fails because the clang supplied by Xcode 7.3 doesn't support thread local storage.

Sounds like the line `compiler.thread_local_storage yes` should be added to the clang-9.0 portfile so that it will automatically use a MacPorts clang instead of an incompatible Xcode clang.


> I could fix this by installing Xcode 8.2, which is the last version that runs on El Capitan. Xcode 8.2 comes with a newer version of clang which does support thread local storage, and that should be able to build clang-9.0.
>
> My issue with this solution is that updating Xcode from 7.3 to 8.2 will delete the older 10.11 SDK and replace it with the 10.12 SDK. I use other ports which will not build if the correct SDK is not found, the first one that comes to mind is mit-scheme. Many times in the past I've had issues building it after upgrading Xcode for this reason.
>
> The only thing I can think of to fix this mess is to save a copy of the 10.11 SDK and then put it back after upgrading Xcode. Is that correct?

Copying the SDK is an option.


On Fri, Feb 12, 2021 at 7:20 AM Ken Cunningham wrote:

> Both clang-8.0 and clang-9.0 having been building properly for us on the buildbots and (when I last did it) locally for me, on ElCap.
>
> See <https://ports.macports.org/port/clang-9.0/summary> and the one for clang-8.0.

Yes but this is evidently because we are using Xcode 8.2.1 on the El Capitan worker, while Christian is and wants to continue using Xcode 7.x.


> If you have a build error with clang 8 or 9, open a ticket and include your log, and we'll what might be wrong.

Indeed.

Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

Ken Cunningham
I would suggest you install Xcode 8.2.1 to match the buildbots.


Don’t forget that in almost all cases, MacPorts will use the SDK installed in “/“ when building software. That SDK is the 10.11 SDK, so it is the one that matches your system, and is the one you want. Virtually all standard “open source software” will use that SDK in “/“ on that system.

The only time that the SDK in Xcode (or the CLTs) is used is if certain software, usually building with Xcode, forces that SDK to be used over the objections of MacPorts (eg qt5, clang’s compiler_rt, etc).

But - I submit - in those cases, you are likely to be OK, because that software more than likely “knows what to do”.


So - for maximum happiness, and maximum compatibility, I suggest you duplicate the BuildBot setup we use as a reference platform, and install Xcode 8.2.1 like Ryan did.


I can’t see that I am going to change the already very complicated Portfiles that we set up to build clang-11 all the way back to 10.6 (and some clangs earlier) for what are non-reference systems.

It sounds simple to add:

compiler.thread_local_storage yes

but it is just not true that that compiler is always needed. That line in MacPorts forces a whole chain of events that we don’t want to rehash, with very unpredictable results. For example, clang-8.0 builds perfectly well on MacOSX 10.6 using a compiler that does not support thread_local storage, because we have worked around that to match the buildbot reference platform.

So — we already go to great lengths to support older systems, but I don’t think it’s too much to ask that users set up their older systems in a consistent way to the buildbots we have.

Best,

Ken


Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

ryandesign2
Administrator


On Feb 13, 2021, at 03:03, Ken Cunningham wrote:

> I would suggest you install Xcode 8.2.1 to match the buildbots.
>
>
> Don’t forget that in almost all cases, MacPorts will use the SDK installed in “/“ when building software. That SDK is the 10.11 SDK, so it is the one that matches your system, and is the one you want. Virtually all standard “open source software” will use that SDK in “/“ on that system.
>
> The only time that the SDK in Xcode (or the CLTs) is used is if certain software, usually building with Xcode, forces that SDK to be used over the objections of MacPorts (eg qt5, clang’s compiler_rt, etc).
>
> But - I submit - in those cases, you are likely to be OK, because that software more than likely “knows what to do”.
>
>
> So - for maximum happiness, and maximum compatibility, I suggest you duplicate the BuildBot setup we use as a reference platform, and install Xcode 8.2.1 like Ryan did.
>
>
> I can’t see that I am going to change the already very complicated Portfiles that we set up to build clang-11 all the way back to 10.6 (and some clangs earlier) for what are non-reference systems.
>
> It sounds simple to add:
>
> compiler.thread_local_storage yes
>
> but it is just not true that that compiler is always needed. That line in MacPorts forces a whole chain of events that we don’t want to rehash, with very unpredictable results. For example, clang-8.0 builds perfectly well on MacOSX 10.6 using a compiler that does not support thread_local storage, because we have worked around that to match the buildbot reference platform.
>
> So — we already go to great lengths to support older systems, but I don’t think it’s too much to ask that users set up their older systems in a consistent way to the buildbots we have.

I would consider it unreasonable to ask users to be aware of the existence of our buildbot infrastructure or what versions of Xcode we have installed on the buildbot workers and to ask them to duplicate it.

I didn't mention that I have Xcode 8.2.1 on the 10.11 buildbot worker in order to suggest that the user should duplicate it. Rather I mentioned it as a way to explain why we could build it and he currently cannot.

Users should feel free to install any version of Xcode that is compatible with their OS version. Most users will probably choose the latest compatible version.

It is fine if not all ports can be built with all Xcode versions, though where possible we should accommodate any compatible Xcode version, such as by using the compiler_blacklist_versions portgroup to blacklist incompatible Xcode clang versions or helpers like compiler.thread_local_storage that abstract away the knowledge of which clang versions support which features. As a last resort, a port could print an error if it cannot build with the currently installed Xcode and could advise the user on which version would be acceptable. I created the xcodeversion portgroup to help you emit such an error message.

I'm not sure what you mean by "compiler.thread_local_storage yes" being "unpredictable". It should very predictably restrict the list of acceptable compilers to those that support thread-local storage, with the exception of the bug that currently exists when compiler.cxx_standard is set greater than 2011 which will be fixed in the next version of MacPorts. If you do not require thread-local storage on 10.6, then you can enclose the directive in a conditional that excludes 10.6.

Note that having Xcode 8.2.1 on the 10.11 buildbot worker makes it unusual among our workers. On most of the other workers, I deliberately do not update to the latest Xcode because I want to keep a version of Xcode that contains the SDK matching the OS version. There is value in that strategy because it avoids a whole host of problems relating to weak symbols, which Josh has mentioned before. One example of that kind of problem is just being discussed in https://trac.macports.org/ticket/62278.


Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

Ken Cunningham


On Feb 13, 2021, at 1:27 AM, Ryan Schmidt <[hidden email]> wrote:


I would consider it unreasonable to ask users to be aware of the existence of our buildbot infrastructure or what versions of Xcode we have installed on the buildbot workers and to ask them to duplicate it.

I didn't mention that I have Xcode 8.2.1 on the 10.11 buildbot worker in order to suggest that the user should duplicate it. Rather I mentioned it as a way to explain why we could build it and he currently cannot.

Users should feel free to install any version of Xcode that is compatible with their OS version. Most users will probably choose the latest compatible version.



It is fine if not all ports can be built with all Xcode versions, though where possible we should accommodate any compatible Xcode version, such as by using the compiler_blacklist_versions portgroup to blacklist incompatible Xcode clang versions or helpers like compiler.thread_local_storage that abstract away the knowledge of which clang versions support which features. As a last resort, a port could print an error if it cannot build with the currently installed Xcode and could advise the user on which version would be acceptable. I created the xcodeversion portgroup to help you emit such an error message.



I'm not sure what you mean by "compiler.thread_local_storage yes" being "unpredictable". It should very predictably restrict the list of acceptable compilers to those that support thread-local storage, with the exception of the bug that currently exists when compiler.cxx_standard is set greater than 2011 which will be fixed in the next version of MacPorts. If you do not require thread-local storage on 10.6, then you can enclose the directive in a conditional that excludes 10.6.


Thread local includes __thread, Thread_local, and thread_local.

The compilers that support them are all different.

To make it easy for people to not think about it much, especially when you’re not talking about bootstrapping compiler, etc, MacPorts base just treats them all the same.

The system clang on 10.7 supports thread_local storage.

But base excludes it because it doesn’t support the “thread_local” keyword.

And 100 more complicated examples I could explain further to you if you are interested in learning more about it.

K


Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

ryandesign2
Administrator


On Feb 13, 2021, at 03:42, Ken Cunningham wrote:

> Thread local includes __thread, Thread_local, and thread_local.
>
> The compilers that support them are all different.
>
> To make it easy for people to not think about it much, especially when you’re not talking about bootstrapping compiler, etc, MacPorts base just treats them all the same.
>
> The system clang on 10.7 supports thread_local storage.
>
> But base excludes it because it doesn’t support the “thread_local” keyword.
>
> And 100 more complicated examples I could explain further to you if you are interested in learning more about it.

Ok, so it sounds like "compiler.thread_local_storage yes" might in some circumstances exclude a compiler that would have been able to build the code. I guess when this option was added to base it was thought to be simpler to have one option that encompasses several related features.

Per this thread, the clang in Xcode 7.3 doesn't have sufficient thread localness to build clang 8 on 10.11 but the clang in Xcode 8.2.1 does. That would seem to suggest that adding "compiler.thread_local_storage yes" would fix it. But a counterargument is that Xcode 7.2.1 is able to build clang 8 on 10.10. So it comes back to needing to see the build log of the failure.

Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

Ken Cunningham
To try to make bootstrapping clang and llvm as workable as possible, the compilers that can build them are carefully tested and the portfile tweaked to manage each one. Sometimes the compilers seem to build them, but the products don't work properly. Sometimes they don't build at all.

MacPorts base has some "broad strokes" compiler settings for thread_local, c++11, c++17, etc -- but these are designed to make it as easy as possible for Portfile authors to select compilers that are sure to work with their software. For example, there is an array of compilers that support varying amounts of c++17 between clang 5 and clang 9, and the matching Xcode system clangs. If we just used the "broad stroke" compiler selection in MacPorts base, we would indeed exclude a whole bunch of clang compilers that might well (and do) work to build a given version of clang. In so doing, that would make bootstrapping more complicated in many ways.

So, in the clang-8.0 Portfile for example we have a selection of hand-tuned blacklisting, started by Jeremy way-back-when, and then extensively tweaked by me afterwards. We (I) tried to cover every situation, but using non-default (or non-common) Xcode installs on the midrange macOS systems between 10.8 and 10.12 is really complicated. I'm usually happy to test each and every default compiler setup on those systems, and I just don't have VMs set up for non-default situations.

When a user comes along with a new report of a combination that doesn't work, I'm happy to tweak the blacklisting, if it is a reliable report on a well-set-up system where the Xcode matchest the CLTs and the SDK is right and the log is clear. I have done that before, and I"m happy to do that again.

The current blacklisting in clang-8.0 looks like this:
{{{
# llvm-3.5 and later requires a C++11 runtime
# Xcode 4.3's clang (318.x) fails per https://trac.macports.org/ticket/44161
# Xcode 4.5's clang (421.11.66) fails due to http://llvm.org/bugs/show_bug.cgi?id=20184
# Xcode 4.6.3's clang (425.0.28) fails due to http://trac.macports.org/ticket/46897
# Xcode 4.6.3's clang (425.0.28) fails due to https://llvm.org/bugs/show_bug.cgi?id=30384
# Xcode 5.1's clang (clang-503.0.40) has codegen issues (resulting compiler crashes)
# Xcode 6.2's clang (600.0.57) fails due to https://llvm.org/bugs/show_bug.cgi?id=25753
compiler.blacklist *gcc* {clang < 602}

# clang older than 3.5 fail due to https://llvm.org/bugs/show_bug.cgi?id=25753
# new llvms build with clang-3.4 but have codegen issues resulting compiler crashes
compiler.blacklist-append macports-clang-3.3 macports-clang-3.4

# Override the normal compiler fallback list entirely since we have
# such specific requirements.
compiler.fallback   clang

# 3.7 is already needed to bootstrap cmake, so is a good last resort
# when the system clang is too old.
if {${os.platform} eq "darwin" && ${os.major} < 18} {
    compiler.fallback-append macports-clang-3.7
}

if {${subport} eq "lldb-${llvm_version}"} {
    # Xcode 6.4's clang (602.0.53) fails to build lldb with 'thread-local storage is not supported for the current target'
    compiler.blacklist-append {clang < 700}
}
}}}

So you can see, we are really trying to allow the maximum number of working compilers and taking aggressive steps to do so.

I could easily just say
{{{
compiler.cxx_standard 2018
compielr.thread_local_storage yes
}}}
and delete all that and forget about it.

I have _no idea_ what kind of wreckage that would throw into our already delicate hand-tuned compiler selection and to be honest I'm not overly interested to spend three weeks figuring that all out for each clang version, when what we have now (except for occasional user setups) has worked exceedingly well, I would think.

So work with me here, and please don't try to make this even harder than it already is by upending what amounts to many hours of work first by Jeremy and then by me to make this work properly.

Ken

On Sat, Feb 13, 2021 at 2:35 AM Ryan Schmidt <[hidden email]> wrote:


On Feb 13, 2021, at 03:42, Ken Cunningham wrote:

> Thread local includes __thread, Thread_local, and thread_local.
>
> The compilers that support them are all different.
>
> To make it easy for people to not think about it much, especially when you’re not talking about bootstrapping compiler, etc, MacPorts base just treats them all the same.
>
> The system clang on 10.7 supports thread_local storage.
>
> But base excludes it because it doesn’t support the “thread_local” keyword.
>
> And 100 more complicated examples I could explain further to you if you are interested in learning more about it.

Ok, so it sounds like "compiler.thread_local_storage yes" might in some circumstances exclude a compiler that would have been able to build the code. I guess when this option was added to base it was thought to be simpler to have one option that encompasses several related features.

Per this thread, the clang in Xcode 7.3 doesn't have sufficient thread localness to build clang 8 on 10.11 but the clang in Xcode 8.2.1 does. That would seem to suggest that adding "compiler.thread_local_storage yes" would fix it. But a counterargument is that Xcode 7.2.1 is able to build clang 8 on 10.10. So it comes back to needing to see the build log of the failure.

Reply | Threaded
Open this post in threaded view
|

Re: Building Clang 8/9 in El Capitan

Ken Cunningham
typo, of course. I meant

compiler.cxx_standard 2017
compiler.thread_local_storage yes

I'm typing this in TenFourFox right now on Tiger ;>

K



On Sat, Feb 13, 2021 at 3:25 PM Ken Cunningham <[hidden email]> wrote:
To try to make bootstrapping clang and llvm as workable as possible, the compilers that can build them are carefully tested and the portfile tweaked to manage each one. Sometimes the compilers seem to build them, but the products don't work properly. Sometimes they don't build at all.

MacPorts base has some "broad strokes" compiler settings for thread_local, c++11, c++17, etc -- but these are designed to make it as easy as possible for Portfile authors to select compilers that are sure to work with their software. For example, there is an array of compilers that support varying amounts of c++17 between clang 5 and clang 9, and the matching Xcode system clangs. If we just used the "broad stroke" compiler selection in MacPorts base, we would indeed exclude a whole bunch of clang compilers that might well (and do) work to build a given version of clang. In so doing, that would make bootstrapping more complicated in many ways.

So, in the clang-8.0 Portfile for example we have a selection of hand-tuned blacklisting, started by Jeremy way-back-when, and then extensively tweaked by me afterwards. We (I) tried to cover every situation, but using non-default (or non-common) Xcode installs on the midrange macOS systems between 10.8 and 10.12 is really complicated. I'm usually happy to test each and every default compiler setup on those systems, and I just don't have VMs set up for non-default situations.

When a user comes along with a new report of a combination that doesn't work, I'm happy to tweak the blacklisting, if it is a reliable report on a well-set-up system where the Xcode matchest the CLTs and the SDK is right and the log is clear. I have done that before, and I"m happy to do that again.

The current blacklisting in clang-8.0 looks like this:
{{{
# llvm-3.5 and later requires a C++11 runtime
# Xcode 4.3's clang (318.x) fails per https://trac.macports.org/ticket/44161
# Xcode 4.5's clang (421.11.66) fails due to http://llvm.org/bugs/show_bug.cgi?id=20184
# Xcode 4.6.3's clang (425.0.28) fails due to http://trac.macports.org/ticket/46897
# Xcode 4.6.3's clang (425.0.28) fails due to https://llvm.org/bugs/show_bug.cgi?id=30384
# Xcode 5.1's clang (clang-503.0.40) has codegen issues (resulting compiler crashes)
# Xcode 6.2's clang (600.0.57) fails due to https://llvm.org/bugs/show_bug.cgi?id=25753
compiler.blacklist *gcc* {clang < 602}

# clang older than 3.5 fail due to https://llvm.org/bugs/show_bug.cgi?id=25753
# new llvms build with clang-3.4 but have codegen issues resulting compiler crashes
compiler.blacklist-append macports-clang-3.3 macports-clang-3.4

# Override the normal compiler fallback list entirely since we have
# such specific requirements.
compiler.fallback   clang

# 3.7 is already needed to bootstrap cmake, so is a good last resort
# when the system clang is too old.
if {${os.platform} eq "darwin" && ${os.major} < 18} {
    compiler.fallback-append macports-clang-3.7
}

if {${subport} eq "lldb-${llvm_version}"} {
    # Xcode 6.4's clang (602.0.53) fails to build lldb with 'thread-local storage is not supported for the current target'
    compiler.blacklist-append {clang < 700}
}
}}}

So you can see, we are really trying to allow the maximum number of working compilers and taking aggressive steps to do so.

I could easily just say
{{{
compiler.cxx_standard 2018
compielr.thread_local_storage yes
}}}
and delete all that and forget about it.

I have _no idea_ what kind of wreckage that would throw into our already delicate hand-tuned compiler selection and to be honest I'm not overly interested to spend three weeks figuring that all out for each clang version, when what we have now (except for occasional user setups) has worked exceedingly well, I would think.

So work with me here, and please don't try to make this even harder than it already is by upending what amounts to many hours of work first by Jeremy and then by me to make this work properly.

Ken

On Sat, Feb 13, 2021 at 2:35 AM Ryan Schmidt <[hidden email]> wrote:


On Feb 13, 2021, at 03:42, Ken Cunningham wrote:

> Thread local includes __thread, Thread_local, and thread_local.
>
> The compilers that support them are all different.
>
> To make it easy for people to not think about it much, especially when you’re not talking about bootstrapping compiler, etc, MacPorts base just treats them all the same.
>
> The system clang on 10.7 supports thread_local storage.
>
> But base excludes it because it doesn’t support the “thread_local” keyword.
>
> And 100 more complicated examples I could explain further to you if you are interested in learning more about it.

Ok, so it sounds like "compiler.thread_local_storage yes" might in some circumstances exclude a compiler that would have been able to build the code. I guess when this option was added to base it was thought to be simpler to have one option that encompasses several related features.

Per this thread, the clang in Xcode 7.3 doesn't have sufficient thread localness to build clang 8 on 10.11 but the clang in Xcode 8.2.1 does. That would seem to suggest that adding "compiler.thread_local_storage yes" would fix it. But a counterargument is that Xcode 7.2.1 is able to build clang 8 on 10.10. So it comes back to needing to see the build log of the failure.