Re: wxMaxima crashes under Big Sur 11.2.1

[Ryan Schmidt]

On Feb 13, 2021, at 11:33, Murray Eisenberg wrote:

> Without complaint, wxMaxima @20.04.0_0 installed (after maxima 
> @5.43.2_12+xmaxima and gnuplot 
> @5.4.1_2+aquaterm+luaterm+pangocairo+qt+wxwidgets+x11) under macOS Big Sur 
> 11.2.1 using MacPorts 2.6.99 and Xcode CLT 12.4.
> 
> Although the command-line maxima works, if I try to open 
> /Applications/MacPorts/wxMaxima.app, the app immediately crashes.
> 
> Perhaps this is related to https://trac.macports.org/ticket/61933. 
> 
> But exactly what log file should I provide? I examined the 
> wxMaxima_2021002-13-.crash file in ~/Library/Logs/DiagnosticReports but 
> find no “rootless” line there.

I'm not sure what "rootless8" mentioned in that ticket refers to. Maybe it is 
the name of the user's computer. Probably irrelevant.

If you want to provide your crash log, you can do that, but it sounds like we 
already figured out what the problem is.

Per the mailing list thread mentioned in that ticket, I think the problem is an 
install_name_tool bug in Xcode 12.2. I don't know if the problem remains in 
Xcode 12.4. If you did not build wxWidgets from source, you can try doing that 
and see if it fixes the problem. Let us know whether or not that fixed it. If 
12.4 didn't fix the bug, then a workaround is given in the mailing list thread 
linked in that ticket.

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 <
ken.cunningham.web...@gmail.com> 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 
> 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 

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 
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 

wxMaxima crashes under Big Sur 11.2.1

[Murray Eisenberg]

Without complaint, wxMaxima @20.04.0_0 installed (after maxima 
@5.43.2_12+xmaxima and gnuplot 
@5.4.1_2+aquaterm+luaterm+pangocairo+qt+wxwidgets+x11) under macOS Big Sur 
11.2.1 using MacPorts 2.6.99 and Xcode CLT 12.4.

Although the command-line maxima works, if I try to open 
/Applications/MacPorts/wxMaxima.app, the app immediately crashes.

Perhaps this is related to https://trac.macports.org/ticket/61933 
. 

But exactly what log file should I provide? I examined the 
wxMaxima_2021002-13-.crash file in ~/Library/Logs/DiagnosticReports but 
find no “rootless” line there.
---
Murray Eisenbergmurrayeisenb...@gmail.com
503 King Farm Blvd #101 
Rockville, MD 20850-6667Mobile (413)-427-5334

Re: Building Clang 8/9 in El Capitan

[Ryan Schmidt]

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.

Re: Building Clang 8/9 in El Capitan

[Ken Cunningham]

> On Feb 13, 2021, at 1:27 AM, Ryan Schmidt  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

Re: Building Clang 8/9 in El Capitan

[Ryan Schmidt]

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. 

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