at Ben was building Sage from source, whereas you're trying to
> modify a binary Sage installation, something that is more error-prone.
> Would you mind trying to build from source instead?
>
>
> On Tue, Oct 8, 2019 at 10:22 PM Zachary Scherr > wrote:
>
>> That makes sen
October 8, 2019 at 4:25:23 PM UTC-4, Dima Pasechnik wrote:
>
> did you try updating homebrew?
>
> I think that what ultimately helped Ben to get a working gfortran, and
> correctly build whatever scipy's dependency is causing the problem.
>
>
> On Tue, Oct 8, 2019 at 3:17 PM
Sage on OSX, you need OSX's
> clang/clang++
> OSX in its infinite wisdom aliases clang to gcc.
>
> One cannot build Sage on OSX with "real" gcc.
> That is, your "gcc" should be /usr/bin/gcc, which is actually clang.
>
>
>
> On Tue, Oct 8, 2019 at
gfortran, so make sure there is no "real" gcc in your
> PATH)
> It's much more likely just the problem of using a binary built of Sage.
>
> On Tue, Oct 8, 2019 at 10:47 PM Zachary Scherr > wrote:
>
>> Will do. It also occurs to me that maybe I should force
Hi,
I recently tried adding openssl to the app.dmg prebuilt sage 9 binary
via: sage -i openssl && sage -f python3. During the rebuild, rpy2 failed
with the message:
[rpy2-2.8.2.p1] dyld: lazy symbol binding failed: Symbol not found:
_timespec_get
[rpy2-2.8.2.p1] Referenced from:
recommendations (installing
gcc@9 will stop gfortran 9 from compiling from scratch) and then running
"source /Applications/sage/.homebrew-build-env" before you configure and
make.
On Tuesday, September 1, 2020 at 6:49:12 PM UTC-4 Zachary Scherr wrote:
> You said that you are running 10.15.6
You said that you are running 10.15.6 but something looks very bizarre with
the python3 that configure is picking up. It looks like it is using
/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7
since this python is first in your PATH.
Could you try running this python and then
HON_CLINE_IN_TRACEBACK=1 -DSING_NDEBUG
> -DOM_NDEBUG -I/Users/zscherr/sage/develop/local/include/singular -std=c++11
>
> On Wednesday, September 9, 2020 at 8:52:07 PM UTC-7, Zachary Scherr wrote:
>>
>>Running ./sage -sh -c 'pkg-config --cflags singular' with home-brew
Hi Matthias,
It's attached to this message.
Best,
Zach
On Thursday, September 10, 2020 at 1:07:27 PM UTC-4 Matthias Koeppe wrote:
> On Thursday, September 10, 2020 at 9:58:02 AM UTC-7, Zachary Scherr wrote:
>>
>>
>> Obviously this is not a big deal since I can just br
c.sagemath.org/attachment/ticket/29024/spkg-configure.m4
>
> - of if you did, you didn't run
>
> make singular-clean
>
> ./bootstrap && ./configure
>
> after putting that file
> in build/pkgs/singular/
>
>
>
>
> Try
>
> CXXFLAGS="$CXXFLAGS -I//usr/l
:18 PM UTC-7, Matthias Koeppe wrote:
>>
>> On Wednesday, September 9, 2020 at 6:49:36 PM UTC-7, Zachary Scherr wrote:
>>>
>>>I tried to build the most recent beta version of sage and it would
>>> appear that it's taking issue with the fact that I have
If you rerun ./configure with
FC=gfortran-9 ./configure
Then it should use gfortran-9 as your Fortran compiler when making sage.
On Tuesday, September 15, 2020 at 3:49:22 PM UTC-4 Gabe Feinberg wrote:
>
> Hi~
> I'm also trying to install from the source code, and I'm receiving an
> error
at it is in SAGE_LOCAL.
>> So this probably can instead by handled using cython_aliases from the
>> same module (which does compute
>> all the needed info for Singular, it seems).
>> Or by fixing _get_shared_lib_filename so that it also searches elsewhere.
>>
>>
>&
lained in
>>>> https://trac.sagemath.org/ticket/29024#comment:8
>>>>
>>>> The fix needs some programming - specifically, the code in singular.pyx
>>>> calls dlopen on SINGULAR_SO,
>>>> which is computed by _get_shared_lib_f
You should probably follow the directions
here: https://doc.sagemath.org/html/en/installation/conda.html
and install sage into its own environment so that it correctly installs all
the dependencies. Sage 9.2 will support python 3.8.
On Wednesday, October 7, 2020 at 2:18:27 PM UTC-4
y insight into why this might be the
>> case?
>>
>> Thanks,
>> Zach
>>
>> On Monday, October 12, 2020 at 4:14:28 PM UTC-4 Zachary Scherr wrote:
>>
>>> Ah, thank you. I'll post the issue and see if I can get homebrew to
>>> resolve it!
&
In an attempt to learn a little bit about sage's build system I was playing
around with building various packages today. From a fresh git clone I can
build the developer branch of my Mac with homebrew without any issues.
However, if I just run
make fflas_ffpack
after going through the usual
.
On Sunday, October 11, 2020 at 8:11:13 PM UTC-4 dim...@gmail.com wrote:
> On Mon, Oct 12, 2020 at 1:00 AM Zachary Scherr wrote:
> >
> > That also crashes with: 86622 segmentation fault ./sage --python
> >
> > I tested this both with building sage against homebrew python
then it
works without problem.
On Sunday, October 11, 2020 at 3:26:11 PM UTC-4 dim...@gmail.com wrote:
> On Sun, Oct 11, 2020 at 8:14 PM Zachary Scherr wrote:
> >
> > Hi All,
> >
> > I was doing some bug hunting and noticed that scipy's pytests crashed
> pretty earl
that openBLAS is bottled with a different processor type than the one that
is on my system. In any case I'll ask over there and see if I can get some
help.
On Sunday, October 11, 2020 at 10:17:43 PM UTC-4 Zachary Scherr wrote:
> Hi Dima,
>
>My system-wide numpy is installed via pip. I
, October 12, 2020 at 1:17:30 PM UTC-4 isu...@gmail.com wrote:
> I looked at the openblas formula in homebrew and they are not passing the
> TARGET option. When using DYNAMIC_ARCH=1, a target should be specified.
>
> Isuru
>
> On Mon, Oct 12, 2020 at 11:34 AM Zachary Scherr wrote:
&
g
> the TARGET option. When using DYNAMIC_ARCH=1, a target should be specified.
>
> care to open an issue with them on
> https://github.com/Homebrew/homebrew-core ?
>
> >
> > Isuru
> >
> > On Mon, Oct 12, 2020 at 11:34 AM Zachary Scherr
> wrote:
> >
tching the CPU
> at runtime. `TARGET` gives the oldest CPU that this code will run on so
> that the common code is compiled to target this.
>
> Isuru
>
> On Mon, Oct 12, 2020 at 1:24 PM Zachary Scherr wrote:
>
>> I posted about it on their discussion page, but I'm no
for
homebrew, then I still run into the same numpy error. I see that
Conda-forge uses TARGET=PRESCOTT, but if I try that I also run into the
same numpy problem. Do you have any insight into why this might be the
case?
Thanks,
Zach
On Monday, October 12, 2020 at 4:14:28 PM UTC-4 Zachary Scherr
Hi All,
I was doing some bug hunting and noticed that scipy's pytests crashed
pretty early. I tracked down exactly what was causing the problem and
noticed it can be reproduced by the following sequence of commands:
sage: import numpy as np
sage: x = np.random.randn(100,2)
sage: y =
Koeppe wrote:
> On Wednesday, October 7, 2020 at 4:42:23 PM UTC-7, Zachary Scherr wrote:
>>
>>I was building sage today, and the building of sage seems to work fine
>> but building the documentation crashed for me at manifolds. Does anyone
>> have any
I should probably also add that while sage builds with
the spkg-configure.m4 fix, my documentation will not build unless I brew
unlink singular.
On Wednesday, October 7, 2020 at 10:33:32 AM UTC-4 Zachary Scherr wrote:
> I was just curious as to what the status of this is
I tried to build the documentation on 9.2 beta 8 and the documentation
building seems to get hang on:
[dochtml]
[dochtml] [thematic_] building [html]: targets for 83 source files that are
out of date
[dochtml] [thematic_] updating environment: [new config] 83 added, 0
changed, 0 removed
When
Ah, thanks.
On Monday, August 17, 2020 at 8:30:23 PM UTC-4 François Bissey wrote:
> You are probably experiencing https://trac.sagemath.org/ticket/30351
>
> > On 18/08/2020, at 12:28 PM, Zachary Scherr wrote:
> >
> > I tried to build the documentation on 9.2 beta
I think you need to run:
sage -i openssl
sage -f python3
and then you should be able to add packages through pip.
On Wednesday, August 26, 2020 at 12:23:20 PM UTC-4 dim...@gmail.com wrote:
> On Wed, Aug 26, 2020 at 5:10 PM David Coudert wrote:
> >
> > Hello,
> >
> > I'm posting this here as
e on 10.14 without these problems.
> >
> > Best,
> > Zach
> >
> > On Monday, June 1, 2020 at 3:27:19 PM UTC-4, Dima Pasechnik wrote:
> >>
> >> On Mon, Jun 1, 2020 at 7:37 PM Zachary Scherr
> wrote:
> >> >
> >>
-4, Dima Pasechnik wrote:
>
> On Mon, Jun 1, 2020 at 7:37 PM Zachary Scherr > wrote:
> >
> > Hi All,
> >
> >I recently tried building Sage on Catalina 10.15.5. I have homebrew
> with all recommended packages installed and I tried building sage via the
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
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,
I think it might be related to Mac having an old version of makeinfo. I
see from your config.log that you use homebrew. To get ECL to build you
can try
brew install texinfo
export PATH="/usr/local/opt/texinfo/bin:$PATH"
and then rerunning configure and make. I haven't tested with sage, but
Hi All,
I just thought I would chime in on the homebrew side of things. I have
freetype installed via homebrew on Catalina 10.15.5 and when I execute
> pkg-config --modversion freetype2
I get back 23.2.17. Anne seemed to get back version 9.8.3, which means
that something is screwy with
/ftheader.h"
is the real file and the others should all be symlinks of this one.
On Wednesday, July 1, 2020 at 8:26:58 AM UTC-4 Zachary Scherr wrote:
> Hi All,
>
>I just thought I would chime in on the homebrew side of things. I have
> freetype installed via homebrew on
I was able to successfully build cryptominisat using an Ubuntu 20.04 docker
image. Some weird things I noticed from your log files:
config log says you have boost lib >= 1.66 yet your cryptominisat log file
says "Boost 1.46 found". On the next line it says:
"-- Found Boost components:
Seems to be related to https://github.com/scipy/scipy/issues/11611 and as
was pointed out above was fixed in version 1.5.
I'd like to propose two workarounds for people who can no longer build sage
and stumble into this thread (either should allow scipy 1.2.3 to build)
1). Use fortran 9:
brew
In an attempt to be helpful I tried to recreate the error with fewer
options to configure. It appears that on Catalina the error is caused by:
./configure --with-system-gp2c=no
On Sunday, July 26, 2020 at 6:00:45 PM UTC-4 Samuel Lelievre wrote:
> 2020-07-25 21:30:25 UTC Samuel Lelièvre:
>
> >
A brief look at the log file suggests that it's using python 2 from
homebrew. Maybe try remove python@2 from homebrew? I don't think they
support it anymore.
On Sunday, July 19, 2020 at 2:55:04 PM UTC-4 dwb...@gmail.com wrote:
> I am trying to build on an iMac running MacOS 10.14.6 (Mojave).
ked).
>
>
> On Saturday, July 18, 2020 at 11:59:03 PM UTC-4, Zachary Scherr wrote:
>>
>> I think it might be related to Mac having an old version of makeinfo. I
>> see from your config.log that you use homebrew. To get ECL to build you
>> can try
>>
>> bre
Maybe somebody with more experience can answer, but the problem is likely
caused by the fact that you used a prebuilt binary of sage and then tried
to remake it on your own computer. What tends to happen in this situation
is that the prebuilt binary was built with a specific version of Xcode
You may want to take a look at with
https://github.com/Homebrew/brew/issues/7857. I think the biggest thing at
the moment is that gfortran won't be available for the M1 for some time.
On Tuesday, November 24, 2020 at 10:47:42 AM UTC-5 kcrisman wrote:
> Hi sage-devel,
>
> The only references I
Just wanted to add that make -j8 doc is also not building in parallel.
On Wednesday, December 2, 2020 at 10:35:05 AM UTC-5 Eric Gourgoulhon wrote:
> Le mercredi 2 décembre 2020 à 14:20:56 UTC+1, vdelecroix a écrit :
>
>> Dear all,
>>
>> For the 9.3.beta2 release the command
>>
>> $ MAKE="make
Have you tried running "brew doctor"? Homebrew should complain loudly about
all of the header files in /usr/local/include which could cause conflicts.
For example, if I touch stdio.h in my /usr/local/include and then I run
brew doctor I get:
"Warning: Unbrewed header files were found in
I just tried building 9.3.beta4 and my build breaks at pillow-7.2.0 on
Catalina 10.15.7.
The actual error is:
[pillow-7.2.0] gcc -Wno-unused-result -Wsign-compare -Wunreachable-code
-fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -I/usr/local/include
-isysroot
You can safely ignore that message. I think there is some ongoing work
being done on changing how sage handles recommended packages and that
message is a byproduct. If it's really bothering you then you can just
type:
make _recommended
and I think that message should disappear.
On Tuesday,
Sorry for the spam today, but after fixing my pillow issue I encountered a
problem with fpylll on 9.3.beta4. The key lines seem to be:
build/src/fpylll/fplll/integer_matrix.cpp:706:10: fatal error:
'fplll/sieve/sieve_gauss.h' file not found
#include "fplll/sieve/sieve_gauss.h"
I have not. I just sourced .homebrew-build-env and then built in the
normal way. I haven't had this problem in the past, but I'm not sure when
homebrew installed libzip on my laptop (I see it is a dependency of php).
I can see in the failing gcc command that -I/usr/local/include comes
before
Hi Matthias,
Thank you. I had forgotten I had fplll installed via homebrew, removing
it fixed my problem.
On Tuesday, December 15, 2020 at 8:32:52 PM UTC-5 Matthias Koeppe wrote:
> Is this with fplll from homebrew?
> Only specific versions of fplll and fpylll work together - in
>
e find the log file
> attached.
> Anyway, I currently build it without documentation by running 'make build'
> only.
> But was curious why documentation fails.
>
> On Wednesday, October 28, 2020 at 8:01:43 PM UTC+1 dim...@gmail.com wrote:
>
>>
>>
>> On W
I posted over on Trac, but I'm new to sage development so I'll repost here.
The cffi issue has been fixed in 1.14.4 so it's probably best to update
that package. I created a https://trac.sagemath.org/ticket/31128 to do
this.
As for scipy, it's possible to get scipy to build in the terminal
Has anyone tried to run "make -j8 ptestlong" on Big Sur? Every time I run
it, doctesting breaks with the following traceback:
Traceback (most recent call last):
File "/Users/zscherr/sage/develop/src/bin/sage-runtests", line 182, in
err = DC.run()
File
Interesting. I've noticed the segfaults in the past, but never the "too
many open files" error. I'll try to play around with my ulimit and see if
I can get the testing to finish.
On Friday, January 8, 2021 at 1:21:20 PM UTC-5 Matthias Koeppe wrote:
> I think this has started to show up, at
For the record, I was able to get make ptestlong it to finish by doing:
ulimit -n 4096
On Friday, January 8, 2021 at 3:30:19 PM UTC-5 Zachary Scherr wrote:
> Interesting. I've noticed the segfaults in the past, but never the "too
> many open files" error. I'll try to pla
If you have SSL installed, say through homebrew, then you can use the
following script: https://github.com/3-manifolds/fix_mac_sage
On Monday, January 25, 2021 at 7:06:08 PM UTC-5 pols...@gmail.com wrote:
> Dear developers of SageMath,
>
> I keep encountering this error (see log attached) with
Actually, it looks like you don't already need SSL installed since it comes
with that fix.
On Monday, January 25, 2021 at 7:10:25 PM UTC-5 Zachary Scherr wrote:
>
> If you have SSL installed, say through homebrew, then you can use the
> following script: https://github.com/3-
UTC-5, Dima Pasechnik wrote:
>
>
>
> On Thu, 14 Jan 2021, 00:52 Zachary Scherr, >
> wrote:
>
>> I've been trying to help out with getting sage to work properly on Mac,
>> and I was curious if anyone can explain the purpose of
>> SAGE_MACOSX_DEPLOYMENT_TA
Did you build sage from source? I had success getting lrslib to build by
running:
CFLAGS=-Wno-implicit-function-declaration make lrslib
if you didn't build from source then you might try
CFLAGS=-Wno-implicit-function-declaration sage -i lrslib
On Thursday, January 14, 2021 at 2:01:36 PM
I've been trying to help out with getting sage to work properly on Mac, and
I was curious if anyone can explain the purpose of
SAGE_MACOSX_DEPLOYMENT_TARGET to me.
I don't know autoconf at all, but I find that if I configure with
--with-system-python3=no
then SAGE_MACOSX_DEPLOYMENT_TARGET gets
For the --with-system-python3=no, I don't know what the problem is but I
think it was fixed by upgrading to python 3.9
in https://trac.sagemath.org/ticket/30589
On Monday, February 1, 2021 at 9:45:37 PM UTC-5 John H Palmieri wrote:
> On OS X Big Sur (intel), as of the most recent Xcode and
I found something possibly relevant at
https://bugs.python.org/issue42691
although there the complaint was that Homebrew built python against system
tcl and the suggestion was that Homebrew use its own tcl-tk. It seems that
Homebrew is correctly using its own tcl-tk
since the line
5
I haven't fully tested this yet, but you can also try installing gcc-10
through homebrew and then using gfortran-10. Here are the steps to try:
> brew install gcc-10
and then once in a clean sage directory (so run make distclean if you need
to):
> source .homebrew-build-env
> make configure
gt; https://wiki.sagemath.org/ReleaseTours/sage-9.3#Availability_of_Sage_9.3_and_installation_help
>
> (it may need expanding)
>
> On Monday, May 10, 2021 at 12:28:50 PM UTC-7 zsc...@gmail.com wrote:
>
>> sorry, that should be `brew install gcc@10`
>>
>> On Monday, May 10, 202
sorry, that should be `brew install gcc@10`
On Monday, May 10, 2021 at 3:27:47 PM UTC-4 Zachary Scherr wrote:
> I haven't fully tested this yet, but you can also try installing gcc-10
> through homebrew and then using gfortran-10. Here are the steps to try:
>
> > brew
t;
> So I tried your second suggestion and it seems to be working so far, but
> it is still compiling.
>
> On Mon, Feb 8, 2021 at 10:29 AM Zachary Scherr wrote:
>
>> Probably the thing to try would be:
>>
>> make distclean
>>
>> and then you can build f
I really don't understand. The Cython log file shows that the problem is in
/Users/trevorkarn/Applications/sage/local/lib/python3.9/site-packages/wheel/pep425tags.py
I could be mistaken, but I don't think pep425tags.py has been a part of the
wheel package for a while now. Certainly when I
and do you see that pep425tags.py file in that directory?
On Monday, February 8, 2021 at 10:21:09 AM UTC-5 Trevor Karn wrote:
> The only contents of the file you pointed me towards are
>
> __version__ = '0.36.2'
>
> Best Regards,
>
> Trevor Karn
>
>
> On Mon,
> Trevor Karn
>
>
> On Mon, Feb 8, 2021 at 9:54 AM Dima Pasechnik wrote:
>
>> the only explanation for pep425tags.py would be an unclean build
>> environment - e.g. weird env vars set, or strange stuff in PATH.
>>
>> On Mon, Feb 8, 2021 at 3:51 PM Zacha
, February 8, 2021 at 2:25:16 PM UTC-5 Trevor Karn wrote:
> I must have typed it wrong. The second option you gave failed on numpy,
> but I tried the first option again, and it is compiling.
>
> Best Regards,
>
> Trevor Karn
>
>
> On Mon, Feb 8, 2021 at 11:31 AM Zachary Scher
now run 'make' again, the build directory of the
>
> same version of the package will, by default, be deleted. Set the
>
> environment variable SAGE_KEEP_BUILT_SPKGS=yes to prevent this.
>
>
> make[1]: *** [all-build] Error 1
>
> make: *** [build] Error 2
>
>
gt; ./configure
Before running "make -j4 build" you can look at config.log and make sure
that it picked up all of the relevant homebrew packages.
On Monday, February 8, 2021 at 10:52:43 PM UTC-5 Trevor Karn wrote:
> Here is the new one. Thanks so much for all of your help on this,
emoving: /usr/local/Cellar/gmp/6.1.2_2... (18 files, 3.1MB)
>
> Removing: /usr/local/Cellar/gnutls/3.6.9... (1,227 files, 9.9MB)
>
> Removing: /usr/local/Cellar/icu4c/64.2... (257 files, 69.2MB)
>
> Removing: /usr/local/Cellar/libevent/2.1.11... (1,063 files, 5MB)
>
> Re
ran --version". That should hopefully
> show you that you have gfortran 10.2.0_3.
> >> >
> >> > - in your sage folder under the develop branch you should run the
> commands I mentioned, and don't skip out on "source .homebrew-build-env":
>
#31166 is already merged into the latest develop branch so you shouldn't
have to merge that. Scipy should build with #31183 so maybe try again and
post the log file. If you need scipy to build you can also do:
MACOSX_DEPLOYMENT_TARGET=11.0 make scipy
which should fix the problem you are
Just wanted to mention that I posted about something similar a few years
ago here:
https://groups.google.com/g/sage-support/c/j1Y9yuu-VuE/m/cA7N8iqCCAAJ. At
the time a trac ticket was opened, but I'm not sure about the status
especially post the github migration.
On Wed, Mar 6, 2024 at 11:55 AM
77 matches
Mail list logo
