Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

Thanks for the kind words.

I just posted a general announcement of the recent release candidate. See
https://groups.google.com/g/sage-devel/c/676IgptcB7I

Something I personally am interested in is interoperability between the
various systems and backends.

One thing that comes to mind is taking WL code and producing Python code
for it. There are a couple of ways this can go.

The easiest is something like this:

#!/usr/bin/env python
from mathics import evaluate
evaluate("""
(* put your WL code here for example: *)
Range[3, 5]
""")


At the next level is using Mathics Expression which uses Python syntax but
WL function as strings:

#!/usr/bin/env python
from mathics import Expression
Expression("Range", 3, 5))

The next level might be calling the Mathics functions (like "Range") more
directly. I won't give an example here.

And finally more along the line of what I had mentioned earlier where even
where simple and reliable cases get translated automatically into Python or
sympy equivalents:

#!/usr/bin/env python
range(3,5)

Within a translation there could be mixtures of all of these, some things
done as strings, some things done as calls to functions, and some things
(probably more of a glue-like nature like range(),  done as translations to
Python and sympy.

The overall idea is not that all of this is automatic and flawless, but
that it could aid translation of WL into some other system of your
choosing.

All of this is a bit ambitious (== vaporware).

However, I'd love to hear other ideas and thoughts as to how to bridge or
bring the various communities together.


On Wed, Oct 28, 2020 at 8:17 AM David Joyner  wrote:

>
> FYI, related to this thread, it looks like Rocky and a few colleagues are
> giving an upcoming talk (2020-10-30) on Mathics at SD110:
> https://researchseminars.org/seminar/SageDays110
>
>
>
> On Mon, Aug 31, 2020 at 1:44 PM Rocky Bernstein 
> wrote:
>
>>
>>
>> On Mon, Aug 31, 2020 at 1:00 PM E. Madison Bray 
>> wrote:
>>
>>> On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
>>>  wrote:
>>> >
>>> > I think we've beat this to death. So let's agree to disagree.
>>> >
>>> > This kind of thing is not intended for someone like you, but rather,
>>> someone like me who is just getting started in Sage and CAS and wants to go
>>> through a number of simple Mma tutorials and see roughly corresponding
>>> results translated to another system. If that works out, I am happy, and
>>> may try more ambitious things.
>>> >
>>> > The specific examples showing how the various systems are hopelessly
>>> incompatible or where there are subtleties and vagueness are interesting.
>>> However I suspect none of this is going to matter. At least not in the
>>> short term, if ever. This is for casual, non-mission-critical, and
>>> educational use.  After I have something that isn't vaporware (if I get to
>>> that stage), you can pop up again and warn people of the dangers. I hear
>>> you, and you have some valid points. Now please go away.
>>> >
>>> > There were the hacks one used to do with calculators where you'd
>>> divide a number of times by a number and then multiply it back and get
>>> something slightly off. Using that, Homer Simpson was able to disprove
>>> Fermat's Theorem by finding a solution to the equation  a**12 + b**12 =
>>> c**12 in TI calculator math. Somehow though, calculators and mathematics
>>> were both able to survive this ordeal.
>>>
>>> I think this is a laudable goal, and while RJF's admonitions are
>>> valid, I don't think it should discourage you from trying to get
>>> something working.
>>
>>
>> Actually, it's had the opposite effect.
>>
>>
>>>   I think even if you can get some simple cases
>>> working it would be very impressive and useful.
>>>
>>
>> What can be handled now is in
>> https://github.com/rocky/FoxySheep2/tree/master/pytest/parse_expressions,
>> And installing should be pretty is as easy as: pip install FoxySheep
>>
>> The main limiting factor is having time, need, or desire to work on it.
>> It feels like there is a great deal that can be done and there is a lot of
>> low-hanging fruit for anyone who wants to work on.
>>
>
>
>
>>
>>
>>> As a technical note I don't think it would be worth trying to
>>> implement this directly in the sage preparser, at least not yet.  That
>>> would be a can of worms.  Just stick to a stand-alone transpiler
>>> program that can parse Mathematica code and spit out some roughly
>>> equivalent Python/Sage code.  This would make the transpilation result
>>> more transparent, and give you (or anyone else using it) opportunity
>>> to review the transpiled code and modify it.  Burying it in the sage
>>> preparser would get too hairy and distract from the primary mission,
>>> and would also make it more obscured.
>>>
>>>
>>>
>>> > On Mon, Jul 13, 2020 at 4:25 PM rjf  wrote:
>>> >>
>>> >> the problem I see here is the recipe
>>> >>
>>> >> requiring "user choice"  and somehow specifying "inf in Mma"
>>> >>
>>> >> Most users will not want to sp

[sage-devel] Mathics 1.1rc1 released

[Rocky Bernstein]

Hey all -

After a gap of 4 years, we've have a new pre-release for Mathics: Mathics 
1.1rc1.

In brief, there are over 50 new built-in functions, and we've updated the 
code so that it now works current releases of the software it uses: Python, 
sympy, Django, etc.

Details of the release can be found on the project github release page 
. 

You can find Python wheels, eggs. and tarballs there as well.

And it is also possible to run from docker. Information on this can be 
found at mathics dockerhub repository 
. 

The pre-release is not currently available from PyPI. That will happen 
though when we do the full release which, unless people report problems, 
may happen in the next couple of weeks.

A lot of people put a lot of effort into this. Thanks to all.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9c2cc42f-a31a-4de0-ab75-732de787025cn%40googlegroups.com.

Re: [sage-devel] Building Sage 9.2 on Mac fails due to cysignals

[Dima Pasechnik]

On Wed, 28 Oct 2020, 14:33 Zachary Scherr,  wrote:

> Hopefully somebody with more experience can weigh in, but for the record I
> have pari installed via homebrew and there the configure is only with
> --with-gmp and --with-readline and that works with building sage.  It's
> plausible that the -mt=pthread is what's causing the issues.
>

Hombrew does not provide Pari packages. Unless you install them manually
(these are just data files)
it will not be used by Sage.

If you install Pari with  -mt=pthread
into /usr/local, with its packages, it will be accepted by Sage, causing
this problem.

Patches to fix this are welcome.
Ideally it can be a short C program to link against libpari, which would
fail with the error message reported on this thread.




> On Wednesday, October 28, 2020 at 10:12:35 AM UTC-4 modp...@gmail.com
> wrote:
>
>> Yes, I have manually installed Pari 2.11.4 after configuring it with:
>> Confgure --mt=pthread --tune
>>
>> On Wednesday, October 28, 2020 at 3:04:01 PM UTC+1 zsc...@gmail.com
>> wrote:
>>
>>> Just wanted to make a couple of comments.  First off, brew installs llvm
>>> as keg-only meaning that sage shouldn't even be able to find it unless you
>>> manually added something like:
>>>
>>> export PATH="/usr/local/opt/llvm/bin:$PATH"
>>> export LDFLAGS="-L/usr/local/opt/llvm/lib"
>>> export CPPFLAGS="-I/usr/local/opt/llvm/include"
>>>
>>> to your profile.  But even after I tried that myself, I failed to
>>> reproduce your error on my own Mac machine.  This makes me think that you
>>> might want to have a look at the version of Pari you installed on your
>>> computer.  I noticed that ./configure finds a copy of Pari in /usr/local on
>>> your computer.  You can see that the specific error it references mentions:
>>>
>>>  ld: illegal thread local variable reference to regular symbol
>>> _PARI_SIGINT_block for architecture x86_64
>>>
>>> If removing llvm and make distclean doesn't solve your problem then you
>>> may want to look into where you got your Pari.  It seems plausible that
>>> Pari might have been built in some funky way and that is what's causing
>>> your issue.
>>> On Wednesday, October 28, 2020 at 7:27:27 AM UTC-4 dim...@gmail.com
>>> wrote:
>>>
 try
 make distclean

 and the build

 On Wed, 28 Oct 2020, 09:57 modp...@gmail.com, 
 wrote:

>
> I tried uninstalling LLVM and building it again, but it fails again
> for cysignals.
> But the problem now seems that it still sets -I and -L flags with
> non-existent LLVM directories.
> On Tuesday, October 27, 2020 at 5:10:58 PM UTC+1 Matthias Koeppe wrote:
>
>> From config.log:
>>
>> configure:5906: gcc -v >&5
>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
>> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>> Apple clang version 12.0.0 (clang-1200.0.32.21)
>> Target: x86_64-apple-darwin19.6.0
>> Thread model: posix
>> InstalledDir: 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>> configure:5917: $? = 0
>> ...
>>
>> configure:6029: gcc -o conftest  -I/usr/local/opt/llvm/include 
>> -L/usr/local/opt/llvm/lib conftest.c  >&5
>>
>>
>> This looks like an unsupported configuration - injecting these -L and
>> -I flags via environment variables, but continuing to use Apple's gcc.
>> If you are trying to compile with homebrew's llvm, you should
>> probably configure by setting CC and CXX as well. But this is also 
>> untested
>> - I have created https://trac.sagemath.org/ticket/30835#ticket for
>> testing such a configuration.
>>
>>
>> On Tuesday, October 27, 2020 at 3:46:10 AM UTC-7, Dima Pasechnik
>> wrote:
>>
>>> I'd have tried removing llvm and trying again. Perhaps this is a
>>> conflict between Homebrew packages.
>>>
>>> On Tue, Oct 27, 2020 at 8:42 AM modp...@gmail.com 
>>> wrote:
>>>
>> Please find config.log and cysignals-1.10.2.log attached. I already
 run "source .homebrew-build-env" before configuring.
 And yes I also have llvm installed through Homebrew.

 On Monday, October 26, 2020 at 3:23:38 PM UTC+1 dim...@gmail.com
 wrote:

> also note that you apparently have something in
> -L/usr/local/opt/llvm/lib (installed from Homebrew ?) which might
> lead
> to surprises.
> Do you have some LDFLAGS set?
> It would help if you also post logs/pkgs/cysignals-1.10.2.log
>
> On Mon, Oct 26, 2020 at 2:15 PM Dima Pasechnik 
> wrote:
> >
> > also, if you have Homebrew, you should run
> >
> > source .homebrew-build-env
> >
> > before
> >
> > ./configure
> >
> > On Mon, Oct 26, 2020

[sage-devel] Re: git clone git://github.com/sagemath/sage.git didn't do what I expected

[Matthias Koeppe]

On Wednesday, October 28, 2020 at 10:34:13 AM UTC-7, Peter Mueller wrote:
>
> I just tried to follow the first few steps from the Developer's Guide 
> v9.2. From that I would have expected that after running "git clone git://
> github.com/sagemath/sage.git" I would find two branches of the source 
> code, namely sage 9.2 as master, and sage 9.3 as develop. However, I only 
> got a single branch named develop, which compiled fine, but turned out to 
> be version 9.2. 
>

Both master and develop are currently at 9.2. This will change when our 
release manager releases 9.3.beta0, which will be pushed to develop, 
whereas master will stay at 9.2.


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3caef35c-4d76-4bb4-b4c3-6d58209f7737o%40googlegroups.com.

[sage-devel] git clone git://github.com/sagemath/sage.git didn't do what I expected

['Peter Mueller' via sage-devel]

I'm sorry if the following is more appropriate for sage-support. I just 
tried to follow the first few steps from the Developer's Guide v9.2. From 
that I would have expected that after running "git clone 
git://github.com/sagemath/sage.git" I would find two branches of the source 
code, namely sage 9.2 as master, and sage 9.3 as develop. However, I only 
got a single branch named develop, which compiled fine, but turned out to 
be version 9.2. Did I do something wrong? Or did git clone from a mirror 
which isn't up to date? Or is Developer's Guide v9.2 outdated? (For 
instance, it doesn't tell that one has to run ./configure before issuing 
make.)

-- Peter Mueller

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3f08b908-750c-4aa7-8daf-fc701e08e5f2o%40googlegroups.com.

Re: [sage-devel] Building Sage 9.2 on Mac fails due to cysignals

[Zachary Scherr]

Hopefully somebody with more experience can weigh in, but for the record I 
have pari installed via homebrew and there the configure is only with 
--with-gmp and --with-readline and that works with building sage.  It's 
plausible that the -mt=pthread is what's causing the issues.

On Wednesday, October 28, 2020 at 10:12:35 AM UTC-4 modp...@gmail.com wrote:

> Yes, I have manually installed Pari 2.11.4 after configuring it with:
> Confgure --mt=pthread --tune
>
> On Wednesday, October 28, 2020 at 3:04:01 PM UTC+1 zsc...@gmail.com wrote:
>
>> Just wanted to make a couple of comments.  First off, brew installs llvm 
>> as keg-only meaning that sage shouldn't even be able to find it unless you 
>> manually added something like:
>>
>> export PATH="/usr/local/opt/llvm/bin:$PATH"
>> export LDFLAGS="-L/usr/local/opt/llvm/lib"
>> export CPPFLAGS="-I/usr/local/opt/llvm/include"
>>
>> to your profile.  But even after I tried that myself, I failed to 
>> reproduce your error on my own Mac machine.  This makes me think that you 
>> might want to have a look at the version of Pari you installed on your 
>> computer.  I noticed that ./configure finds a copy of Pari in /usr/local on 
>> your computer.  You can see that the specific error it references mentions:
>>
>>  ld: illegal thread local variable reference to regular symbol 
>> _PARI_SIGINT_block for architecture x86_64
>>
>> If removing llvm and make distclean doesn't solve your problem then you 
>> may want to look into where you got your Pari.  It seems plausible that 
>> Pari might have been built in some funky way and that is what's causing 
>> your issue. 
>> On Wednesday, October 28, 2020 at 7:27:27 AM UTC-4 dim...@gmail.com 
>> wrote:
>>
>>> try 
>>> make distclean
>>>
>>> and the build 
>>>
>>> On Wed, 28 Oct 2020, 09:57 modp...@gmail.com,  wrote:
>>>

 I tried uninstalling LLVM and building it again, but it fails again for 
 cysignals. 
 But the problem now seems that it still sets -I and -L flags with 
 non-existent LLVM directories.
 On Tuesday, October 27, 2020 at 5:10:58 PM UTC+1 Matthias Koeppe wrote:

> From config.log:
>
> configure:5906: gcc -v >&5
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
> Apple clang version 12.0.0 (clang-1200.0.32.21)
> Target: x86_64-apple-darwin19.6.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> configure:5917: $? = 0
> ...
>
> configure:6029: gcc -o conftest  -I/usr/local/opt/llvm/include 
> -L/usr/local/opt/llvm/lib conftest.c  >&5
>
>
> This looks like an unsupported configuration - injecting these -L and 
> -I flags via environment variables, but continuing to use Apple's gcc.
> If you are trying to compile with homebrew's llvm, you should probably 
> configure by setting CC and CXX as well. But this is also untested - I 
> have 
> created https://trac.sagemath.org/ticket/30835#ticket for testing 
> such a configuration.
>
>
> On Tuesday, October 27, 2020 at 3:46:10 AM UTC-7, Dima Pasechnik wrote:
>
>> I'd have tried removing llvm and trying again. Perhaps this is a 
>> conflict between Homebrew packages.
>>
>> On Tue, Oct 27, 2020 at 8:42 AM modp...@gmail.com  
>> wrote:
>>
> Please find config.log and cysignals-1.10.2.log attached. I already 
>>> run "source .homebrew-build-env" before configuring.
>>> And yes I also have llvm installed through Homebrew.
>>>
>>> On Monday, October 26, 2020 at 3:23:38 PM UTC+1 dim...@gmail.com 
>>> wrote:
>>>
 also note that you apparently have something in 
 -L/usr/local/opt/llvm/lib (installed from Homebrew ?) which might 
 lead 
 to surprises. 
 Do you have some LDFLAGS set? 
 It would help if you also post logs/pkgs/cysignals-1.10.2.log 

 On Mon, Oct 26, 2020 at 2:15 PM Dima Pasechnik  
 wrote: 
 > 
 > also, if you have Homebrew, you should run 
 > 
 > source .homebrew-build-env 
 > 
 > before 
 > 
 > ./configure 
 > 
 > On Mon, Oct 26, 2020 at 1:50 PM Dima Pasechnik  
 wrote: 
 >> 
 >> please post the top-level config.log here 
 >> 
 >> On Mon, 26 Oct 2020, 13:45 modp...@gmail.com,  
 wrote: 
 >>> 
 >>> 
 >>> I'm building Sage 9.2 from source on macOS Catalina 10.15.7, 
 however, it fails 
 >>> when trying to install cysignals. More precisely, it throws the 
 following error: 
 >>> 
 >>> gcc -bundle -undefined dynamic_lookup -isysroot 
 /Applications/Xcode.app/Contents/De

Re: [sage-devel] Building Sage 9.2 on Mac fails due to cysignals

[Dima Pasechnik]

On Wed, 28 Oct 2020, 14:12 modp...@gmail.com,  wrote:

> Yes, I have manually installed Pari 2.11.4 after configuring it with:
> Confgure --mt=pthread --tune
>

this it the cause of your problem, as Sage doesn't work with threaded
libpari.


> On Wednesday, October 28, 2020 at 3:04:01 PM UTC+1 zsc...@gmail.com wrote:
>
>> Just wanted to make a couple of comments.  First off, brew installs llvm
>> as keg-only meaning that sage shouldn't even be able to find it unless you
>> manually added something like:
>>
>> export PATH="/usr/local/opt/llvm/bin:$PATH"
>> export LDFLAGS="-L/usr/local/opt/llvm/lib"
>> export CPPFLAGS="-I/usr/local/opt/llvm/include"
>>
>> to your profile.  But even after I tried that myself, I failed to
>> reproduce your error on my own Mac machine.  This makes me think that you
>> might want to have a look at the version of Pari you installed on your
>> computer.  I noticed that ./configure finds a copy of Pari in /usr/local on
>> your computer.  You can see that the specific error it references mentions:
>>
>>  ld: illegal thread local variable reference to regular symbol
>> _PARI_SIGINT_block for architecture x86_64
>>
>> If removing llvm and make distclean doesn't solve your problem then you
>> may want to look into where you got your Pari.  It seems plausible that
>> Pari might have been built in some funky way and that is what's causing
>> your issue.
>> On Wednesday, October 28, 2020 at 7:27:27 AM UTC-4 dim...@gmail.com
>> wrote:
>>
>>> try
>>> make distclean
>>>
>>> and the build
>>>
>>> On Wed, 28 Oct 2020, 09:57 modp...@gmail.com,  wrote:
>>>

 I tried uninstalling LLVM and building it again, but it fails again for
 cysignals.
 But the problem now seems that it still sets -I and -L flags with
 non-existent LLVM directories.
 On Tuesday, October 27, 2020 at 5:10:58 PM UTC+1 Matthias Koeppe wrote:

> From config.log:
>
> configure:5906: gcc -v >&5
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
> Apple clang version 12.0.0 (clang-1200.0.32.21)
> Target: x86_64-apple-darwin19.6.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> configure:5917: $? = 0
> ...
>
> configure:6029: gcc -o conftest  -I/usr/local/opt/llvm/include 
> -L/usr/local/opt/llvm/lib conftest.c  >&5
>
>
> This looks like an unsupported configuration - injecting these -L and
> -I flags via environment variables, but continuing to use Apple's gcc.
> If you are trying to compile with homebrew's llvm, you should probably
> configure by setting CC and CXX as well. But this is also untested - I 
> have
> created https://trac.sagemath.org/ticket/30835#ticket for testing
> such a configuration.
>
>
> On Tuesday, October 27, 2020 at 3:46:10 AM UTC-7, Dima Pasechnik wrote:
>
>> I'd have tried removing llvm and trying again. Perhaps this is a
>> conflict between Homebrew packages.
>>
>> On Tue, Oct 27, 2020 at 8:42 AM modp...@gmail.com 
>> wrote:
>>
> Please find config.log and cysignals-1.10.2.log attached. I already
>>> run "source .homebrew-build-env" before configuring.
>>> And yes I also have llvm installed through Homebrew.
>>>
>>> On Monday, October 26, 2020 at 3:23:38 PM UTC+1 dim...@gmail.com
>>> wrote:
>>>
 also note that you apparently have something in
 -L/usr/local/opt/llvm/lib (installed from Homebrew ?) which might
 lead
 to surprises.
 Do you have some LDFLAGS set?
 It would help if you also post logs/pkgs/cysignals-1.10.2.log

 On Mon, Oct 26, 2020 at 2:15 PM Dima Pasechnik 
 wrote:
 >
 > also, if you have Homebrew, you should run
 >
 > source .homebrew-build-env
 >
 > before
 >
 > ./configure
 >
 > On Mon, Oct 26, 2020 at 1:50 PM Dima Pasechnik 
 wrote:
 >>
 >> please post the top-level config.log here
 >>
 >> On Mon, 26 Oct 2020, 13:45 modp...@gmail.com, 
 wrote:
 >>>
 >>>
 >>> I'm building Sage 9.2 from source on macOS Catalina 10.15.7,
 however, it fails
 >>> when trying to install cysignals. More precisely, it throws the
 following error:
 >>>
 >>> gcc -bundle -undefined dynamic_lookup -isysroot
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
 -L/Users/myUser/app/sage-9.2/local/lib
 -Wl,-rpath,/Users/myUser/app/sage-9.2/local/lib 
 -L/usr/local/opt/llvm/lib
 -I/usr/local/opt/llvm/include -Wp,-U_FORTIFY_SOURCE
 buil

Re: [sage-devel] Building Sage 9.2 on Mac fails due to cysignals

[modp...@gmail.com]

Yes, I have manually installed Pari 2.11.4 after configuring it with:
Confgure --mt=pthread --tune

On Wednesday, October 28, 2020 at 3:04:01 PM UTC+1 zsc...@gmail.com wrote:

> Just wanted to make a couple of comments.  First off, brew installs llvm 
> as keg-only meaning that sage shouldn't even be able to find it unless you 
> manually added something like:
>
> export PATH="/usr/local/opt/llvm/bin:$PATH"
> export LDFLAGS="-L/usr/local/opt/llvm/lib"
> export CPPFLAGS="-I/usr/local/opt/llvm/include"
>
> to your profile.  But even after I tried that myself, I failed to 
> reproduce your error on my own Mac machine.  This makes me think that you 
> might want to have a look at the version of Pari you installed on your 
> computer.  I noticed that ./configure finds a copy of Pari in /usr/local on 
> your computer.  You can see that the specific error it references mentions:
>
>  ld: illegal thread local variable reference to regular symbol 
> _PARI_SIGINT_block for architecture x86_64
>
> If removing llvm and make distclean doesn't solve your problem then you 
> may want to look into where you got your Pari.  It seems plausible that 
> Pari might have been built in some funky way and that is what's causing 
> your issue. 
> On Wednesday, October 28, 2020 at 7:27:27 AM UTC-4 dim...@gmail.com wrote:
>
>> try 
>> make distclean
>>
>> and the build 
>>
>> On Wed, 28 Oct 2020, 09:57 modp...@gmail.com,  wrote:
>>
>>>
>>> I tried uninstalling LLVM and building it again, but it fails again for 
>>> cysignals. 
>>> But the problem now seems that it still sets -I and -L flags with 
>>> non-existent LLVM directories.
>>> On Tuesday, October 27, 2020 at 5:10:58 PM UTC+1 Matthias Koeppe wrote:
>>>
 From config.log:

 configure:5906: gcc -v >&5
 Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
 --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
 Apple clang version 12.0.0 (clang-1200.0.32.21)
 Target: x86_64-apple-darwin19.6.0
 Thread model: posix
 InstalledDir: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 configure:5917: $? = 0
 ...

 configure:6029: gcc -o conftest  -I/usr/local/opt/llvm/include 
 -L/usr/local/opt/llvm/lib conftest.c  >&5


 This looks like an unsupported configuration - injecting these -L and 
 -I flags via environment variables, but continuing to use Apple's gcc.
 If you are trying to compile with homebrew's llvm, you should probably 
 configure by setting CC and CXX as well. But this is also untested - I 
 have 
 created https://trac.sagemath.org/ticket/30835#ticket for testing such 
 a configuration.


 On Tuesday, October 27, 2020 at 3:46:10 AM UTC-7, Dima Pasechnik wrote:

> I'd have tried removing llvm and trying again. Perhaps this is a 
> conflict between Homebrew packages.
>
> On Tue, Oct 27, 2020 at 8:42 AM modp...@gmail.com  
> wrote:
>
 Please find config.log and cysignals-1.10.2.log attached. I already run 
>> "source .homebrew-build-env" before configuring.
>> And yes I also have llvm installed through Homebrew.
>>
>> On Monday, October 26, 2020 at 3:23:38 PM UTC+1 dim...@gmail.com 
>> wrote:
>>
>>> also note that you apparently have something in 
>>> -L/usr/local/opt/llvm/lib (installed from Homebrew ?) which might 
>>> lead 
>>> to surprises. 
>>> Do you have some LDFLAGS set? 
>>> It would help if you also post logs/pkgs/cysignals-1.10.2.log 
>>>
>>> On Mon, Oct 26, 2020 at 2:15 PM Dima Pasechnik  
>>> wrote: 
>>> > 
>>> > also, if you have Homebrew, you should run 
>>> > 
>>> > source .homebrew-build-env 
>>> > 
>>> > before 
>>> > 
>>> > ./configure 
>>> > 
>>> > On Mon, Oct 26, 2020 at 1:50 PM Dima Pasechnik  
>>> wrote: 
>>> >> 
>>> >> please post the top-level config.log here 
>>> >> 
>>> >> On Mon, 26 Oct 2020, 13:45 modp...@gmail.com,  
>>> wrote: 
>>> >>> 
>>> >>> 
>>> >>> I'm building Sage 9.2 from source on macOS Catalina 10.15.7, 
>>> however, it fails 
>>> >>> when trying to install cysignals. More precisely, it throws the 
>>> following error: 
>>> >>> 
>>> >>> gcc -bundle -undefined dynamic_lookup -isysroot 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
>>>  
>>> -L/Users/myUser/app/sage-9.2/local/lib 
>>> -Wl,-rpath,/Users/myUser/app/sage-9.2/local/lib 
>>> -L/usr/local/opt/llvm/lib 
>>> -I/usr/local/opt/llvm/include -Wp,-U_FORTIFY_SOURCE 
>>> build/temp.macosx-10.15-x86_64-3.8/build/src/cysignals/signals.o 
>>> -L/usr/local/lib -L/usr/local/opt/openssl@1.1/lib 
>>> -L/usr/local/opt/sqlite/lib -o 
>>> build/lib.macosx-10.15-x86_

Re: [sage-devel] Building Sage 9.2 on Mac fails due to cysignals

[Zachary Scherr]

Just wanted to make a couple of comments.  First off, brew installs llvm as 
keg-only meaning that sage shouldn't even be able to find it unless you 
manually added something like:

export PATH="/usr/local/opt/llvm/bin:$PATH"
export LDFLAGS="-L/usr/local/opt/llvm/lib"
export CPPFLAGS="-I/usr/local/opt/llvm/include"

to your profile.  But even after I tried that myself, I failed to reproduce 
your error on my own Mac machine.  This makes me think that you might want 
to have a look at the version of Pari you installed on your computer.  I 
noticed that ./configure finds a copy of Pari in /usr/local on your 
computer.  You can see that the specific error it references mentions:

 ld: illegal thread local variable reference to regular symbol 
_PARI_SIGINT_block for architecture x86_64

If removing llvm and make distclean doesn't solve your problem then you may 
want to look into where you got your Pari.  It seems plausible that Pari 
might have been built in some funky way and that is what's causing your 
issue. 
On Wednesday, October 28, 2020 at 7:27:27 AM UTC-4 dim...@gmail.com wrote:

> try 
> make distclean
>
> and the build 
>
> On Wed, 28 Oct 2020, 09:57 modp...@gmail.com,  wrote:
>
>>
>> I tried uninstalling LLVM and building it again, but it fails again for 
>> cysignals. 
>> But the problem now seems that it still sets -I and -L flags with 
>> non-existent LLVM directories.
>> On Tuesday, October 27, 2020 at 5:10:58 PM UTC+1 Matthias Koeppe wrote:
>>
>>> From config.log:
>>>
>>> configure:5906: gcc -v >&5
>>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
>>> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>>> Apple clang version 12.0.0 (clang-1200.0.32.21)
>>> Target: x86_64-apple-darwin19.6.0
>>> Thread model: posix
>>> InstalledDir: 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>>> configure:5917: $? = 0
>>> ...
>>>
>>> configure:6029: gcc -o conftest  -I/usr/local/opt/llvm/include 
>>> -L/usr/local/opt/llvm/lib conftest.c  >&5
>>>
>>>
>>> This looks like an unsupported configuration - injecting these -L and -I 
>>> flags via environment variables, but continuing to use Apple's gcc.
>>> If you are trying to compile with homebrew's llvm, you should probably 
>>> configure by setting CC and CXX as well. But this is also untested - I have 
>>> created https://trac.sagemath.org/ticket/30835#ticket for testing such 
>>> a configuration.
>>>
>>>
>>> On Tuesday, October 27, 2020 at 3:46:10 AM UTC-7, Dima Pasechnik wrote:
>>>
 I'd have tried removing llvm and trying again. Perhaps this is a 
 conflict between Homebrew packages.

 On Tue, Oct 27, 2020 at 8:42 AM modp...@gmail.com  
 wrote:

>>> Please find config.log and cysignals-1.10.2.log attached. I already run 
> "source .homebrew-build-env" before configuring.
> And yes I also have llvm installed through Homebrew.
>
> On Monday, October 26, 2020 at 3:23:38 PM UTC+1 dim...@gmail.com 
> wrote:
>
>> also note that you apparently have something in 
>> -L/usr/local/opt/llvm/lib (installed from Homebrew ?) which might 
>> lead 
>> to surprises. 
>> Do you have some LDFLAGS set? 
>> It would help if you also post logs/pkgs/cysignals-1.10.2.log 
>>
>> On Mon, Oct 26, 2020 at 2:15 PM Dima Pasechnik  
>> wrote: 
>> > 
>> > also, if you have Homebrew, you should run 
>> > 
>> > source .homebrew-build-env 
>> > 
>> > before 
>> > 
>> > ./configure 
>> > 
>> > On Mon, Oct 26, 2020 at 1:50 PM Dima Pasechnik  
>> wrote: 
>> >> 
>> >> please post the top-level config.log here 
>> >> 
>> >> On Mon, 26 Oct 2020, 13:45 modp...@gmail.com,  
>> wrote: 
>> >>> 
>> >>> 
>> >>> I'm building Sage 9.2 from source on macOS Catalina 10.15.7, 
>> however, it fails 
>> >>> when trying to install cysignals. More precisely, it throws the 
>> following error: 
>> >>> 
>> >>> gcc -bundle -undefined dynamic_lookup -isysroot 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
>>  
>> -L/Users/myUser/app/sage-9.2/local/lib 
>> -Wl,-rpath,/Users/myUser/app/sage-9.2/local/lib 
>> -L/usr/local/opt/llvm/lib 
>> -I/usr/local/opt/llvm/include -Wp,-U_FORTIFY_SOURCE 
>> build/temp.macosx-10.15-x86_64-3.8/build/src/cysignals/signals.o 
>> -L/usr/local/lib -L/usr/local/opt/openssl@1.1/lib 
>> -L/usr/local/opt/sqlite/lib -o 
>> build/lib.macosx-10.15-x86_64-3.8/cysignals/
>> signals.cpython-38-darwin.so -lpari -pthread 
>> >>> ld: illegal thread local variable reference to regular symbol 
>> _PARI_SIGINT_block for architecture x86_64 
>> >>> clang: error: linker command failed with exit code 1 (use -v to 
>> see invocation) 
>> >>> error: comman

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[David Joyner]

FYI, related to this thread, it looks like Rocky and a few colleagues are
giving an upcoming talk (2020-10-30) on Mathics at SD110:
https://researchseminars.org/seminar/SageDays110



On Mon, Aug 31, 2020 at 1:44 PM Rocky Bernstein 
wrote:

>
>
> On Mon, Aug 31, 2020 at 1:00 PM E. Madison Bray 
> wrote:
>
>> On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
>>  wrote:
>> >
>> > I think we've beat this to death. So let's agree to disagree.
>> >
>> > This kind of thing is not intended for someone like you, but rather,
>> someone like me who is just getting started in Sage and CAS and wants to go
>> through a number of simple Mma tutorials and see roughly corresponding
>> results translated to another system. If that works out, I am happy, and
>> may try more ambitious things.
>> >
>> > The specific examples showing how the various systems are hopelessly
>> incompatible or where there are subtleties and vagueness are interesting.
>> However I suspect none of this is going to matter. At least not in the
>> short term, if ever. This is for casual, non-mission-critical, and
>> educational use.  After I have something that isn't vaporware (if I get to
>> that stage), you can pop up again and warn people of the dangers. I hear
>> you, and you have some valid points. Now please go away.
>> >
>> > There were the hacks one used to do with calculators where you'd divide
>> a number of times by a number and then multiply it back and get something
>> slightly off. Using that, Homer Simpson was able to disprove Fermat's
>> Theorem by finding a solution to the equation  a**12 + b**12 = c**12 in TI
>> calculator math. Somehow though, calculators and mathematics were both able
>> to survive this ordeal.
>>
>> I think this is a laudable goal, and while RJF's admonitions are
>> valid, I don't think it should discourage you from trying to get
>> something working.
>
>
> Actually, it's had the opposite effect.
>
>
>>   I think even if you can get some simple cases
>> working it would be very impressive and useful.
>>
>
> What can be handled now is in
> https://github.com/rocky/FoxySheep2/tree/master/pytest/parse_expressions,
> And installing should be pretty is as easy as: pip install FoxySheep
>
> The main limiting factor is having time, need, or desire to work on it. It
> feels like there is a great deal that can be done and there is a lot of
> low-hanging fruit for anyone who wants to work on.
>



>
>
>> As a technical note I don't think it would be worth trying to
>> implement this directly in the sage preparser, at least not yet.  That
>> would be a can of worms.  Just stick to a stand-alone transpiler
>> program that can parse Mathematica code and spit out some roughly
>> equivalent Python/Sage code.  This would make the transpilation result
>> more transparent, and give you (or anyone else using it) opportunity
>> to review the transpiled code and modify it.  Burying it in the sage
>> preparser would get too hairy and distract from the primary mission,
>> and would also make it more obscured.
>>
>>
>>
>> > On Mon, Jul 13, 2020 at 4:25 PM rjf  wrote:
>> >>
>> >> the problem I see here is the recipe
>> >>
>> >> requiring "user choice"  and somehow specifying "inf in Mma"
>> >>
>> >> Most users will not want to specify, but probably would go along with
>> >> "the mathematically consistent choice according to experts who have
>> >> studied the matter."
>> >>
>> >> Certainly saying, as one choice, "inf in Mma" is inadequate since
>> >> the user, other people, other CAS, cannot make use of this with
>> >> any certainty.  Even "inf in Mma version 12.1" while specific,
>> >> is not so useful outside of Mma version 12.1.  There is no
>> >> axiomatic specification for "inf in Mma". Also the code
>> >> supporting it is secret.
>> >>
>> >> Being approximately right in mathematics is different from
>> >> providing an answer which is right within some defined
>> >> level of approximation  (e.g.  numerical precision,  number
>> >> of terms in a series, approximation by polynomial, ...)
>> >>
>> >> If you consider a robotic automated vehicle, being
>> >> approximately right might means it will only rarely crash
>> >> into a tree.  Being right approximately means that it
>> >> will (always) drive to its destination, give-or-take a short
>> displacement.
>> >>
>> >> RJF
>> >>
>> >>
>> >>
>> >>
>> >> On Friday, July 10, 2020 at 6:51:15 PM UTC-7, Rocky Bernstein wrote:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> User choice by option: If you want loose compatibility, then Inf in
>> Mma. If you want strict compatibility there is a strict compatibility
>> library and you can define SageInf in Mma.
>> >>>
>> 
>> 
>> >> I rarely use Google Translate.  I often use voice recognition (Alexa)
>> which is remarkable but
>> >> prone to errors in recognition as well as information retrieval. Maybe
>> you should build your
>> >> system for math voice parsing?  Alexa responds to
>> >> "Alexa, how much is 2+3?"
>> >> with "2+3 is 5".
>> >>
>> >> You can s

Re: [sage-devel] Building Sage 9.2 on Mac fails due to cysignals

[Dima Pasechnik]

try
make distclean

and the build

On Wed, 28 Oct 2020, 09:57 modp...@gmail.com,  wrote:

>
> I tried uninstalling LLVM and building it again, but it fails again for
> cysignals.
> But the problem now seems that it still sets -I and -L flags with
> non-existent LLVM directories.
> On Tuesday, October 27, 2020 at 5:10:58 PM UTC+1 Matthias Koeppe wrote:
>
>> From config.log:
>>
>> configure:5906: gcc -v >&5
>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
>> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>> Apple clang version 12.0.0 (clang-1200.0.32.21)
>> Target: x86_64-apple-darwin19.6.0
>> Thread model: posix
>> InstalledDir: 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>> configure:5917: $? = 0
>> ...
>>
>> configure:6029: gcc -o conftest  -I/usr/local/opt/llvm/include 
>> -L/usr/local/opt/llvm/lib conftest.c  >&5
>>
>>
>> This looks like an unsupported configuration - injecting these -L and -I
>> flags via environment variables, but continuing to use Apple's gcc.
>> If you are trying to compile with homebrew's llvm, you should probably
>> configure by setting CC and CXX as well. But this is also untested - I have
>> created https://trac.sagemath.org/ticket/30835#ticket for testing such a
>> configuration.
>>
>>
>> On Tuesday, October 27, 2020 at 3:46:10 AM UTC-7, Dima Pasechnik wrote:
>>
>>> I'd have tried removing llvm and trying again. Perhaps this is a
>>> conflict between Homebrew packages.
>>>
>>> On Tue, Oct 27, 2020 at 8:42 AM modp...@gmail.com 
>>> wrote:
>>>
>> Please find config.log and cysignals-1.10.2.log attached. I already run
 "source .homebrew-build-env" before configuring.
 And yes I also have llvm installed through Homebrew.

 On Monday, October 26, 2020 at 3:23:38 PM UTC+1 dim...@gmail.com wrote:

> also note that you apparently have something in
> -L/usr/local/opt/llvm/lib (installed from Homebrew ?) which might lead
> to surprises.
> Do you have some LDFLAGS set?
> It would help if you also post logs/pkgs/cysignals-1.10.2.log
>
> On Mon, Oct 26, 2020 at 2:15 PM Dima Pasechnik 
> wrote:
> >
> > also, if you have Homebrew, you should run
> >
> > source .homebrew-build-env
> >
> > before
> >
> > ./configure
> >
> > On Mon, Oct 26, 2020 at 1:50 PM Dima Pasechnik 
> wrote:
> >>
> >> please post the top-level config.log here
> >>
> >> On Mon, 26 Oct 2020, 13:45 modp...@gmail.com, 
> wrote:
> >>>
> >>>
> >>> I'm building Sage 9.2 from source on macOS Catalina 10.15.7,
> however, it fails
> >>> when trying to install cysignals. More precisely, it throws the
> following error:
> >>>
> >>> gcc -bundle -undefined dynamic_lookup -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
> -L/Users/myUser/app/sage-9.2/local/lib
> -Wl,-rpath,/Users/myUser/app/sage-9.2/local/lib -L/usr/local/opt/llvm/lib
> -I/usr/local/opt/llvm/include -Wp,-U_FORTIFY_SOURCE
> build/temp.macosx-10.15-x86_64-3.8/build/src/cysignals/signals.o
> -L/usr/local/lib -L/usr/local/opt/openssl@1.1/lib
> -L/usr/local/opt/sqlite/lib -o 
> build/lib.macosx-10.15-x86_64-3.8/cysignals/
> signals.cpython-38-darwin.so -lpari -pthread
> >>> ld: illegal thread local variable reference to regular symbol
> _PARI_SIGINT_block for architecture x86_64
> >>> clang: error: linker command failed with exit code 1 (use -v to
> see invocation)
> >>> error: command 'gcc' failed with exit status 1
> >>> Building wheel for cysignals (setup.py): finished with status
> 'error'
> >>> ERROR: Failed building wheel for cysignals
> >>>
> >>> This is my compiler version:
> >>>
> >>> Configured with:
> --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>
> >>> Apple clang version 12.0.0 (clang-1200.0.32.21)
> >>> Target: x86_64-apple-darwin19.6.0
> >>> Thread model: posix
> >>> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> >>>
> >>> Any idea what the problem might be, and how to solve it?
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> >>> To unsubscribe from this group and stop receiving emails from it,
> send an email to sage-devel+...@googlegroups.com.
> >>> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/38ff74b7-a4bf-4118-8519-9f57736ba532n%40googlegroups.com.
>
>
 --
 You received this message because y

Re: [sage-devel] Building Sage 9.2 on Mac fails due to cysignals

[modp...@gmail.com]

I tried uninstalling LLVM and building it again, but it fails again for 
cysignals. 
But the problem now seems that it still sets -I and -L flags with 
non-existent LLVM directories.
On Tuesday, October 27, 2020 at 5:10:58 PM UTC+1 Matthias Koeppe wrote:

> From config.log:
>
> configure:5906: gcc -v >&5
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
> Apple clang version 12.0.0 (clang-1200.0.32.21)
> Target: x86_64-apple-darwin19.6.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> configure:5917: $? = 0
> ...
>
> configure:6029: gcc -o conftest  -I/usr/local/opt/llvm/include 
> -L/usr/local/opt/llvm/lib conftest.c  >&5
>
>
> This looks like an unsupported configuration - injecting these -L and -I 
> flags via environment variables, but continuing to use Apple's gcc.
> If you are trying to compile with homebrew's llvm, you should probably 
> configure by setting CC and CXX as well. But this is also untested - I have 
> created https://trac.sagemath.org/ticket/30835#ticket for testing such a 
> configuration.
>
>
> On Tuesday, October 27, 2020 at 3:46:10 AM UTC-7, Dima Pasechnik wrote:
>
>> I'd have tried removing llvm and trying again. Perhaps this is a conflict 
>> between Homebrew packages.
>>
>> On Tue, Oct 27, 2020 at 8:42 AM modp...@gmail.com  
>> wrote:
>>
> Please find config.log and cysignals-1.10.2.log attached. I already run 
>>> "source .homebrew-build-env" before configuring.
>>> And yes I also have llvm installed through Homebrew.
>>>
>>> On Monday, October 26, 2020 at 3:23:38 PM UTC+1 dim...@gmail.com wrote:
>>>
 also note that you apparently have something in 
 -L/usr/local/opt/llvm/lib (installed from Homebrew ?) which might lead 
 to surprises. 
 Do you have some LDFLAGS set? 
 It would help if you also post logs/pkgs/cysignals-1.10.2.log 

 On Mon, Oct 26, 2020 at 2:15 PM Dima Pasechnik  
 wrote: 
 > 
 > also, if you have Homebrew, you should run 
 > 
 > source .homebrew-build-env 
 > 
 > before 
 > 
 > ./configure 
 > 
 > On Mon, Oct 26, 2020 at 1:50 PM Dima Pasechnik  
 wrote: 
 >> 
 >> please post the top-level config.log here 
 >> 
 >> On Mon, 26 Oct 2020, 13:45 modp...@gmail.com,  
 wrote: 
 >>> 
 >>> 
 >>> I'm building Sage 9.2 from source on macOS Catalina 10.15.7, 
 however, it fails 
 >>> when trying to install cysignals. More precisely, it throws the 
 following error: 
 >>> 
 >>> gcc -bundle -undefined dynamic_lookup -isysroot 
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
  
 -L/Users/myUser/app/sage-9.2/local/lib 
 -Wl,-rpath,/Users/myUser/app/sage-9.2/local/lib -L/usr/local/opt/llvm/lib 
 -I/usr/local/opt/llvm/include -Wp,-U_FORTIFY_SOURCE 
 build/temp.macosx-10.15-x86_64-3.8/build/src/cysignals/signals.o 
 -L/usr/local/lib -L/usr/local/opt/openssl@1.1/lib 
 -L/usr/local/opt/sqlite/lib -o build/lib.macosx-10.15-x86_64-3.8/cysignals/
 signals.cpython-38-darwin.so -lpari -pthread 
 >>> ld: illegal thread local variable reference to regular symbol 
 _PARI_SIGINT_block for architecture x86_64 
 >>> clang: error: linker command failed with exit code 1 (use -v to see 
 invocation) 
 >>> error: command 'gcc' failed with exit status 1 
 >>> Building wheel for cysignals (setup.py): finished with status 
 'error' 
 >>> ERROR: Failed building wheel for cysignals 
 >>> 
 >>> This is my compiler version: 
 >>> 
 >>> Configured with: 
 --prefix=/Applications/Xcode.app/Contents/Developer/usr 
 --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
  

 >>> Apple clang version 12.0.0 (clang-1200.0.32.21) 
 >>> Target: x86_64-apple-darwin19.6.0 
 >>> Thread model: posix 
 >>> InstalledDir: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
  

 >>> 
 >>> Any idea what the problem might be, and how to solve it? 
 >>> 
 >>> -- 
 >>> You received this message because you are subscribed to the Google 
 Groups "sage-devel" group. 
 >>> To unsubscribe from this group and stop receiving emails from it, 
 send an email to sage-devel+...@googlegroups.com. 
 >>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/38ff74b7-a4bf-4118-8519-9f57736ba532n%40googlegroups.com.
  


>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "sage-devel" group.
>>>
>> To unsubscribe from this group and stop receiving