Usually not that long :(
We are not especially well organised I am sorry to say.
You will get an account shortly.
François
> On 9/08/2017, at 19:15, Hilder Vitor Lima Pereira
> wrote:
>
> Hi,
>
>
> I have sent an e-mail to sage-trac-acco...@googlegroups.com asking for an
> account, but it w
> On 3/06/2017, at 18:04, Ralf Stephan wrote:
>
> On Friday, June 2, 2017 at 10:48:19 PM UTC+2, François wrote:
> Only used by sage. Those are the components linked to it
>
> Naive questions (maybe irrelevant): Shouldn't it be only libs/pynac
> that is linked to libpynac? Are the direct links
> On 3/06/2017, at 05:28, Nils Bruin wrote:
>
> On Friday, June 2, 2017 at 2:54:22 AM UTC-6, Ralf Stephan wrote:
> No. See
> https://stackoverflow.com/questions/44322187/binary-using-both-python-c-api-version-2-and-3
>
> But then we need to either build libraries libpynac2 and libpynac3 or put
> On 1/06/2017, at 23:27, Kwankyu Lee wrote:
>
> I also thought about building both py2+3 at the same time, it would be a
> great debugging help during the transition if you can easily run both. Then
> in 3 years we'll just cut out the py2 part and be done with it...
>
> I am thinking of what
> On 2/06/2017, at 20:54, Ralf Stephan wrote:
>
> No. See
> https://stackoverflow.com/questions/44322187/binary-using-both-python-c-api-version-2-and-3
So much for that then.
This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canter
> On 2/06/2017, at 17:57, Ralf Stephan wrote:
>
> On Thursday, June 1, 2017 at 12:29:23 PM UTC+2, François wrote:
> .. Installing pynac for both python at the same time
> means rethinking its packaging.
>
> As a possible alternative, would avoiding those calls that differ
> between version 2
I am currently doing a python2+python3 build in sage-on-gentoo.
I need none of the hack currently studied for the script, they
may end up being counter productive for sage-on-distro, we’ll
have to see.
Doing a python2+python3 at the same time in the same prefix
is challenging because of brial (
> On 26/05/2017, at 15:28, Nils Bruin wrote:
>
> On Thursday, May 25, 2017 at 6:40:18 PM UTC-7, François wrote:
> I am a bit surprised you can do that. I have just sent a PR to pynac
> a couple of days ago to have it build with python3.
> https://github.com/pynac/pynac/pull/248
> I have a fee
I am a bit surprised you can do that. I have just sent a PR to pynac
a couple of days ago to have it build with python3.
https://github.com/pynac/pynac/pull/248
I have a feeling you still a python2 pynac.
François
> On 25/05/2017, at 20:49, Frédéric Chapoton wrote:
>
> ok, now with 8.0.b8, you
> On 18/05/2017, at 21:37, Jeroen Demeyer wrote:
>
> On 2017-05-18 11:25, Francois Bissey wrote:
>> Puzzled me for a while too. It doesn’t.
>
> So you are saying that BRiAl consists of two *independent* parts which don't
> interact at all? That by itself w
On 18/05/2017, at 21:24, Jeroen Demeyer wrote:
>
> On 2017-05-18 01:09, François Bissey wrote:
>> And I have a pure
>> python pybrial that install with a minimal setup.py.
>
> If it's pure Python, then how does it access the libBRiAl library?
>
Puzzled me for a while too. It doesn’t.
--
You
I am confident cmake can now be moved to optional. I took care
of all of the problems I could see on OS X and helped with the
ones on other platforms.
Do we need some kind of vote for moving from experimental to
optional?
> On 15/05/2017, at 07:19, Dima Pasechnik wrote:
>
> +1, also for cmake u
Building an old gcc with a newer gcc is not recommended.
Can you give us more details (logs) of the failure with ppl
instead?
François
> On 11/05/2017, at 13:44, Brent Thomas wrote:
>
> I have been trying to install sage on a raspberry pi 3. I didn't find a
> binary of any recent version, so I
> On 29/04/2017, at 22:14, Francois Bissey
> wrote:
>
> We could check whether its use has been re-introduced somewhere else after
> that
A scan on a sphinx 1.5.3 install says that iftex is not used by sphinx.
I’d say you are somehow still on sphinx 1.4.4 or something stra
Well it looks like in 1.4.4 they shipped iftex but then in
https://github.com/sphinx-doc/sphinx/commit/ead753eaad7e0f73f106c4bda918f916b6d3638c
they removed it again. Because they stopped using it.
We could check whether its use has been re-introduced somewhere else after
that, I guess.
François
> On 29/04/2017, at 21:30, Daniel Krenn wrote:
>
> On 2017-04-29 11:27, Daniel Krenn wrote:
>> Building the pdf version of the documentation e.g. for
>> reference/asymptotic fails in the current beta (8.0.beta4). It also
>> fails in 8.0.beta2, but works in 7.6.
>>
>> What can cause this?
>
> F
Can you post the “log file” quoted in the error message please?
It is hard to figure out what went wrong without it.
François
> On 20/04/2017, at 07:30, Anna Haensch wrote:
>
> I'm trying to build sage from source code on a MacBookPro running OSX 10.9
> and Xcode 6.2 with command line tools i
OK 7.5.1 and 7.6 have the same version of openblas, so something else changed
to cause the build failure.
So, yes try to build 7.5.1 again. If it fails now, the cause is likely a change
in
the host system. If it succeeds that’s probably something else in sage that
changed.
> On 11/04/2017, at 1
My build says halswell
perl ./gensymbol osx x86_64 _ 1 0 0 0 0 0 "" "" 1 > osx.def
gcc -O2 -DMAX_STACK_ALLOC=2048 -DEXPRECISION -m128bit-long-double -Wall -m64
-DF_INTERFACE_GFORT -fPIC -DNO_WARMUP -DMAX_CPU_NUMBER=4 -DASMNAME=_
-DASMFNAME=__ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\"
t -v
> xcode-select version 2347.
>
> Are you at the same level?
>
> François
>
> > On 11/04/2017, at 08:03, Francois Bissey
> > wrote:
> >
> > It makes shifting to clang a bit more urgent. I will look into that
> > particular fault
>
I don’t seem to be able to reproduce the problem. I have Xcode 8.3.1 and
Mirage:~ fbissey$ xcode-select -v
xcode-select version 2347.
Are you at the same level?
François
> On 11/04/2017, at 08:03, Francois Bissey
> wrote:
>
> It makes shifting to clang a bit more urgent. I wi
Did it start happening with openblas 0.2.19 or did it suddenly happen
one release build openblas 0.2.19 successfully and the next didn’t?
I suspect it is a CPU detection problem, we have seen similar logs
before on atom chips.
François
> On 11/04/2017, at 07:45, Ackbach wrote:
>
> Having issues
It makes shifting to clang a bit more urgent. I will look into that particular
fault
ASAP.
François
> On 11/04/2017, at 07:58, Volker Braun wrote:
>
> The most recent Xcode update seems to have broken openblas on the OSX
> buildbot. Build log errors start at:
>
>
>
> gcc -c -O2 -DMAX_STACK
> On 6/04/2017, at 10:10, John H Palmieri wrote:
>
> Did that subject line get your attention?
>
> I propose that we remove the symbolic link SAGE_LOCAL/lib/python, keeping the
> two directories SAGE_LOCAL/lib/python2.7 and SAGE_LOCAL/lib/python3.5. The
> link points to python2.7 by default.
> On 5/04/2017, at 11:25, Nils Bruin wrote:
>
> On Tuesday, April 4, 2017 at 4:01:50 PM UTC-7, François wrote:
>
> With the current system you could install and then remove
> some essential files manually and the doctesting framework
> would still try to use it. It is installed according to t
> On 5/04/2017, at 10:41, Nils Bruin wrote:
>
> On Tuesday, April 4, 2017 at 2:24:52 PM UTC-7, François wrote:
> Let’s be clear, I could ship a list of possible
> optional packages supported in sage-on-gentoo
> but any checking of package availability would
> have to go through the the distri
> On 5/04/2017, at 08:42, Nils Bruin wrote:
>
> On Tuesday, April 4, 2017 at 1:00:31 PM UTC-7, François wrote:
> (2) while being just one use, is probably not replaceable.
> Not in this form at the very least.
>
> How can one get the appropriate information in sage-on-gentoo? If we compare
>
> On 5/04/2017, at 01:12, kcrisman wrote:
>
>
> I am starting this debate because of discussion I had earlier
> in #22670. It was pointed out to me that there was no policy
> of avoiding `sage.misc.package` and I would very much want one.
>
>
> This seems very reasonable, given how much wo
> On 28/03/2017, at 21:07, Francois Bissey
> wrote:
>
>> Does such "#distutils: libraries = blah " automatically imply that libblah
>> from $SAGE_LOCAL/lib/ will be linked?
>>
>
> Unless you add -L$some_path, it should be the first one tried. If i
> On 28/03/2017, at 21:04, Dima Pasechnik wrote:
>
>
>
> On Tuesday, March 28, 2017 at 8:32:53 AM UTC+1, Jeroen Demeyer wrote:
> On 2017-03-27 23:15, François Bissey wrote:
> > The generated sage/ext/interpreters/wrapper_cdf.pxd has the following
> > statement:
> > cimport sage.libs.cypari2
Sounds like what “module”/lmod are supposed to do automatically
for you. Sourcing sage-env effectively give you a sage shell
as you would if you run “sage -sh”. Again there is not really
a deactivation. It starts a new shell and once you type exit
you are out.
But you could try to work out someth
> On 13/03/2017, at 07:34, Justin C. Walker wrote:
>
>
> On Mar 12, 2017, at 00:27 , Dima Pasechnik wrote:
>
>> there is no "issue" with pandoc. Most linux distros allow you to install it
>> using package manager, and it is easy to install it on OSX or Windows.
>>
>> On the other hand, it ap
> On 12/03/2017, at 21:38, Jeroen Demeyer wrote:
>
> On 2017-03-12 09:35, Dima Pasechnik wrote:
>> X11?
>
> That can be disabled with --disable-gui
Indeed X absence is not fatal in configure unlike libjpeg.
I guess my point is that before saying it needs porting it should
be tested in somethin
Apart from dependencies like jpeg what’s the problem with surf?
François
> On 12/03/2017, at 21:27, Dima Pasechnik wrote:
>
> there is no "issue" with pandoc. Most linux distros allow you to install it
> using package manager, and it is easy to install it on OSX or Windows.
>
> On the other h
> and ran ./sage as root once. "sage -root" correctly gives /opt/sage. But now
> when I run Sage as root or user, I get this crash.
>
> On Thursday, March 9, 2017 at 1:33:19 PM UTC-7, François wrote:
> Is this a re-located install?
>
> Francois
>
> --
> You
doctesting will fail but building is OK, if dangerous if you are not sandboxed
one way or another.
François
> On 8/03/2017, at 18:59, John H Palmieri wrote:
>
> Although it's not a good idea to build Sage as root. I think it is likely to
> fail -- someone please correct me if I'm wrong.
--
Y
Not at all. It has to do with sage’s python including this patch
https://github.com/sagemath/sage/blob/master/build/pkgs/python2/patches/sys_path_security-issue_16202.patch
it is something that Dima mentioned earlier in the thread.
François
> On 8/03/2017, at 15:24, Gere Mia wrote:
>
> Does thi
Apart from a possible unusual version of make could you
try
MAKE=“make -d” ./sage -p tachyon
That will generate a lot of output but there could be a clue
as to why it tries to go in a folder - which is totally abnormal.
François
> On 7/03/2017, at 06:35, Gere Mia wrote:
>
> I get this build e
Oh I see, so you will go with clang all the way because that’s the default.
I guess you know the score at https://trac.sagemath.org/ticket/12426
it compiles but doctests are failing left and right. But I haven’t had time
to touch the thing in 3 months.
Francois
> On 26/02/2017, at 20:49, Is
why some python extensions with C++ as the language are compiled
> with -std=c99? I'm using sage-7.5.1
>
> Log is below
>
> https://travis-ci.org/isuruf/staged-recipes/builds/205439821#L6669
>
> Regards,
>
> Isuru Fernando
>
> On Tue, Oct 4, 2016 at 1:14 PM,
Output of
cat /proc/cpuinfo
please.
> On 7/02/2017, at 19:58, Jori Mäntysalo wrote:
>
> Just for fun I tried to compile SageMath on an old iMac with 1 GB RAM and 2 x
> T7400 Intel Core 2.
>
> It stops when compiling m4rie, see
> http://www.sis.uta.fi/~jm58660/m4rie-20150908.txt for a full
I can have a look.
François
> On 1/02/2017, at 03:43, Jean-Pierre Flori wrote:
>
> On a POWER7 (ppc64), giac looks very broken in the spirit of:
> * http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=19&t=1723
> I've opened:
> * https://trac.sagemath.org/ticket/22280
>
> --
> You received thi
That was my suspicion. Now does sage-on-cygwin use openblas?
If not that means the corresponding `.pc` files have to be filled
with something appropriate before installing any blas/lapack dependencies.
The present hack I introduced in gsl and causes this error is to force
the linking of libgsl to
Need to see
/home/Owner/sage/local/var/tmp/sage/build/gsl-2.1.p1/src/config.log
but I suspect I am responsible.
François
> On 24/01/2017, at 14:51, Frank Garvan wrote:
>
>
> Have attached log file.
>
> Can this be fixed?
>
> Thanks
>
> PS: Running cygwin64 on windows10
> processor: Intel Co
line 292 to 297 of configure.ac.
François
> On 16/01/2017, at 20:58, Emmanuel Charpentier
> wrote:
>
> Dear list,
>
> The git standard package is not installed when the system on whic Sage is
> built has a systemwide version of git.
>
> I have been unable to find where the logic of this dec
I now see that was indeed the problem. No easy to solve it sage side without
dropping the experimental polymake package or never building the singular
interface to it.
Considering version problems between singular and polymake, the later would be
my inclination.
Francois
On 13/01/2017, at 7
Would you happen to have polymake installed system wide?
Francois
On 13/01/2017, at 12:29 AM, moritz
mailto:mor...@math.fu-berlin.de>> wrote:
When trying to build sage from source on my debian box with a current sid
install, I get the following error:
[singular-4.1.0p1] ../../../g
Don't think so. Look at the logs at the messages about Sed during configure.
Sed is used to preprocess that file.
Gentoo report
https://bugs.gentoo.org/show_bug.cgi?id=604764
I think Bill will have to look at it upstream.
Francois
On 11/01/2017, at 9:23 AM, Dima Pasechnik
mailto
I have seen a report for this in Gentoo
Against 2.6.0. I think it is because of the behaviour of the latest version of
Sed.
Francois
On 10/01/2017, at 1:53 AM, moritz
mailto:mor...@math.fu-berlin.de>> wrote:
Dear list,
I am trying to build sage from source on a thinkpad X240 running
Very relevant. Which version of (lib)sodium do you have installed through
anaconda? You probably have a version of zeromq installed as well.
sodium is an optional dependency of zeromq, an automatic one, so your
install of sodium from anaconda has been detected but somehow the path
is not set for th
> On 7/12/2016, at 21:15, Jeroen Demeyer wrote:
>
> On 2016-12-07 04:17, Francois Bissey wrote:
>> But I am not sure how to do the
>> __new__ = object.__new__ in cython.
>
> You certainly cannot do that since Cython's __new__ does non-trivial stuff
> like
I am guessing we should something more fundamental in
sage/structure/sage_object.pyx
since we are dealing with SageObject classes.
But I am not sure how to do the
__new__ = object.__new__ in cython.
François
> On 7/12/2016, at 15:25, than...@debian.org wrote:
>
> When setting __new__ = object.
> On 3/12/2016, at 22:00, Jeroen Demeyer wrote:
>
> On 2016-12-02 09:21, Thierry wrote:
>> Would it be
>> preferable to have this possibility dealt at configure time
>
> Absolutely. Whatever you do, do *NOT* introduce a new environment variable.
> Use a configure option instead.
Actually no n
it inside Sage?
Manual all the way, eh? So “SYSTEM_BLAS_PC” pointing to pc files for blas, cblas
and lapack. Difficulty, at least on OS X we cannot assume a system pkg-config
to be present, so validation of pc file at configure time is of the menu -
at least by invoking pkg-config.
Francois
--
> On 2/12/2016, at 21:21, Thierry wrote:
>
> Hi,
>
> the SAGE_ATLAS_LIB stuff, which allowed to use system blas belongs to
> SAGE_ROOT/build/pkgs/atlas/spkg-install Is it possible to have such option
> (perhaps renamed SAGE_BLAS_LIB) available even if openblas is selected as
> the default blas,
I notice anaconda ship its own openssl, on OS X at least.
Are they purposefully avoid GPL in all their packages?
François
> On 2/12/2016, at 11:47, Volker Braun wrote:
>
> On OSX, you can do either
>
> a) nothing => no https support,
>
> a) supply the (missing) openssl headers for the system
see https://trac.sagemath.org/ticket/18920
> On 29/11/2016, at 10:26, Paul Masson wrote:
>
> The version of Maxima that ships with Sage is 5.35.1 from December 2014,
> while the most recent version is 5.38.1 from May 2016.
>
> Is there a compelling reason not to upgrade this package? Surely som
configure.in are certainly a bad indicator. Anything with one
of these instead of configure.ac triggers a warning in gentoo
that support for it will be dropped sooner than later.
In any case what kind of changes do you want to apply, I
may have better luck with my packaging machinery.
François
>
This is https://trac.sagemath.org/ticket/21782 I believe it is in the latest
beta
for upcoming sage 7.5.
François
> On 22/11/2016, at 20:36, Eric Culver wrote:
>
> I downloaded the Sage source from
> http://www.sagemath.org/download-source.html .
> When attempting to build, there is an error
It is probably not limited to El Capitan it would have been useful to get some
more details.
Francois
On 3/11/2016, at 2:07 PM, Paul Masson
mailto:paulmas...@comcast.net>> wrote:
I had difficulty over the last couple days getting Sage 7.4 to build. Something
like ten packages would f
There is currently an issue with brial and gcc 6.2.0 that remains to
be fixed. I don’t remember if someone blacklisted that gcc as a consequence.
I should do something about that, even if it is a bit radical.
François
> On 1/11/2016, at 09:55, William Stein wrote:
>
> On Mon, Oct 31, 2016 at 1
Add
trac.sagemath.org,104.197.143.230 ecdsa-sha2-nistp256
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBG+/AO490umZWuczUgClP4BgFm5XR9I43z4kf9f+pu8Uj6UvH/7Pz1oBkJ71xET+xTmecBHB2c9OwlgPjB70AB8=
as a single line at the end of .ssh/know_hosts
François
> On 31/10/2016, at 20:52, Marco Cognetta
Then, it may have been the wrong host.
You should remove the line starting with
trac.sagemath.org
Once removed, the next time you connect to the trac
server, you will be asked about adding it to the list of
know_hosts.
François
> On 31/10/2016, at 20:27, Marco Cognetta wrote:
>
> I have done t
Removing the 4th line in your file
~/.ssh/known_hosts
looks like it would do the trick.
I think it would be the 4th line but it could be
another one. It will almost certainly be another one
for other people.
François
> On 31/10/2016, at 20:10, Marco Cognetta wrote:
>
> What is the fix for this
It is a most interesting point because it explain why
the R binary installed from epel for RH7.1 and family
isn’t linked to openssl.
If they don’t have a rock solid argument, and even if they
have, there may not be anymore official R packages from big
league binary distros. Unless they patch R, t
While not configurable by the user in R-3.2.x it would build if
libcurl wasn’t found or missing https support.
The change to bail out if you don’t fulfil all the condition appear
deliberate to me. And I see the point from a support point of view.
My conclusion is that R developers would fill it a
n Demeyer wrote:
> On 2016-10-27 11:29, Francois Bissey wrote:
> > R package system include downloading facility from repositories.
>
> That's fine but it should be possible to just run R without it's
> packaging system.
> Then I suggest a new solution:
> [666]
R package system include downloading facility from repositories.
That’s why you need curl. At least in theory.
I’ll have to check for 3.3.x but there was alternatives in 3.2.x.
François
> On 27/10/2016, at 22:26, Jeroen Demeyer wrote:
>
> This is the obvious answer:
>
>> [6] or patch R not to
Yup. It is all system packages. In fact R and its dependencies
are not part of the sage-on-gentoo “repo”.
Also in Gentoo we don’t usually split things in $package and
$package-devel you get the nice libraries for linking and headers.
The headers and stuff in $package-devel is the sticky point
when
"Invalid/won't fix"...
>
> --
> Emmanuel Charpentier
>
>
> Le 21 oct. 2016 10:22, "Francois Bissey" a
> écrit :
> Doesn’t have to use .pc - directly. But it has to be able to accept a user
> configuration one way or another. Using .pc to provide sai
-lapack options. You could
solve your problem by doing
—with-lapack=-lopenblas
or to keep with Volker spirit
—with-lapack=`pkg-cong —libs lapack`
Francois
> On 21/10/2016, at 21:14, Emmanuel Charpentier
> wrote:
>
> While it is the "right" solution, it seems a bit heavy handed
I agree it would be best. Unfortunately it may not always be possible
to do that without heavy hacking.
Adding the liblapack link has trade-off, it would make some stuff work
out of the box but it could also hide problems on the long term.
Really upstream of any project using blas/lapack needs to
libopenblas.so to liblapack.so? Yes it should and I think we even should do
it in spkg-install. Feel free to open a ticket.
François
> On 21/10/2016, at 10:23, Emmanuel Charpentier
> wrote:
>
> Would it be sufficient to link libosympenblas.so to liblapack.so in
> $SAGE_ROOT/local/lib/ ?
>
>
This is because automatic blas/lapack detection is a hopeless task.
You should pass your lapack libraries to the configuration script.
If you can’t, hack it.
And now that we have switched to openblas, -lopenblas provides lapack.
François
> On 21/10/2016, at 10:04, Emmanuel Charpentier
> wrote:
Very much appreciated Martin! Since this ticket doesn’t touch
sagelib Gentoo, Debian and other distributions will be able to
use fpylll-0.23 directly in sage-7.4. I’ll issue a revision of
the sage-7.4 ebuild tomorrow and review the ticket if no one
has done it by then.
François
> On 19/10/2016,
And posted to libsingular-devel:
https://groups.google.com/d/msg/libsingular-devel/u8-aHNMqf44/GNVvSYGEAQAJ
> On 18/10/2016, at 21:39, Jean-Pierre Flori wrote:
>
>
>
> On Tuesday, October 18, 2016 at 8:52:23 AM UTC+2, François wrote:
>
> > On 18/10/2016, at 19:42, Jean-Pierre Flori wrote:
I probably assumed too much. But it felt wrong to say
“there is a problem building ntl but ntl upstream is happy
to talk to you about your needs” (and doing that anonymously
feels like a prank call).
I prefer the mailing list option and I am actually subscribed.
Still have to get to it.
François
> On 18/10/2016, at 19:42, Jean-Pierre Flori wrote:
>
>
>
> On Tuesday, October 18, 2016 at 6:37:49 AM UTC+2, Victor Shoup wrote:
> Good! But it should be determined if there is an interface that ntl could
> provide so that this problem goes away
>
> I think that what you suggested: extracti
> On 18/10/2016, at 17:18, Victor Shoup wrote:
>
> I see. I don't do it on purpose...
> I looked at some singular source files, but I don't know if I have the most
> recent. But it looks like they are trying to look inside ntl's ZZ
> representation. That's a big no no. Right now, the only s
> On 18/10/2016, at 16:49, Victor Shoup wrote:
>
> Interesting. Looks like the singular code is using internal, undocumented NTL
> interfaces. I work very hard to keep the documented interfaces stable and
> reliable, but I can't guarantee anything for undocumented interfaces. If
> singular i
> On 17/10/2016, at 22:42, Erik Bray wrote:
>
> On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey
> wrote:
>>
>>> On 17/10/2016, at 22:33, Erik Bray wrote:
>>>
>>> My point is, as it is I see no way to divine when or why a Sage
>>> rele
> On 17/10/2016, at 22:33, Erik Bray wrote:
>
> My point is, as it is I see no way to divine when or why a Sage
> release is coming out.
Release early, release often. In my experience in the last 8 years,
especially release often - it has slowed down a bit, but it is still
often by any means.
T
Not spending the time compiling gcc to get gfortran?
François
> On 13/10/2016, at 22:01, Sébastien Labbé wrote:
>
>
>
> On Wednesday, October 12, 2016 at 9:07:24 PM UTC+2, Eric Gourgoulhon wrote:
> > with Ubuntu 16.04, if you install the Ubuntu package gfortran-5, your Sage
> > build will us
You mean like https://trac.sagemath.org/ticket/12426 ?
François
> On 12/10/2016, at 22:48, Dima Pasechnik wrote:
>
> I see, thanks. I should have been cc'ng myself on #21567 long ago.
>
> Anyway, is it the time we open a meta-ticket on enabling full build of Sage
> with clang(++) ?
> (and cre
Ok the initial problem was with avx instructions. Either givaro gets
misconfigured in thinking you have avx or someone you get a broken assembler.
Can you try
CXXFLAGS=“-Wa,-q” ./sage -i givaro
> On 12/10/2016, at 16:41, Anne Schilling wrote:
>
> Wait, isn't this the error I started with before
I am surprised you got that far with Xcode 8.0!
see https://trac.sagemath.org/ticket/21567
François
> On 12/10/2016, at 07:35, Anne Schilling wrote:
>
> Hi Volker,
>
> Thanks for the suggestion. I upgraded to OSX 10.12 and installed the latest
> version command line xcode. Now I get the foll
> On 12/10/2016, at 06:54, Victor Shoup wrote:
>
> While I'm not ready to go all autotools, I've started reading about it.
> I read about the DESTDIR trick that some package managers use,
> so I added support for that in the makefile. Although I suppose
> that may not be so relevant for Sage.
probably require
> > gmake (GNU make), calling AIX make in the
> > middle is not a good idea.
> >
> >
> > Perhaps the most natural solution would be to change NTL build system so
> > that
> > it uses the standard autotools chain (autoconf/automake
it ought to be an easy task.
>
> Given that I am perhaps the only person in this thread who learned to program
> using punch cards,
> I am a dinosaur from an earlier period, yet, I look into the future :-)
>
> Dima
>
>
>
> Francois
>
> --
> You
> On 9/10/2016, at 09:21, Victor Shoup wrote:
>
> • I've renamed all the ".c" files to ".cpp" files in the Unix
> distribution. This seems to be more in line with common practice, and should
> make it easier to work with compilers and other software development tools.
>
I have been doi
openmp is disabled in linbox/ffpack-fflas so it must come from somewhere else.
Only R seems to be linked to libgomp (openmp) on my vanilla install.
Curiosity: do you observe the same behaviour in 7.3?
François
> On 5/10/2016, at 07:26, Jonathan Bober wrote:
>
> See the following timings: If I s
> On 4/10/2016, at 20:39, Ralf Stephan wrote:
>
> Ah that would be a wrong libffi-devel version on OpenSuSE, shouldn't
> this be tested by Sage configure?
>
That would explain. Note that I only tested the odd package on linux and
most of what I have done has been on OS X. So there definitely c
You need https://trac.sagemath.org/ticket/12473 for ratpoints.
coming in the next beta.
François
> On 4/10/2016, at 19:07, Ralf Stephan wrote:
>
> On Sunday, October 2, 2016 at 10:33:38 PM UTC+2, François wrote:
> this is the status after about two weeks
>
> ratpoints compiles for you? On Lin
I haven’t tried SAGE_INSTALL_GCC=no on linux or using clang
for a full build on linux. Just one packages here and there.
And yes you cannot build gfortran without gcc a t this time.
François
> On 3/10/2016, at 22:48, Dima Pasechnik wrote:
>
> And how about Linux with clang(++) and gfortran ins
In the current state of sage starting from scratch with clang/clang++
via
CC=clang CXX=clang++ make
will trigger the building of sage’s gcc (which is OK on OS X since
you still need gfortran).
The problem is that once you build sage’s gcc, there is a clause
in src/bin/sage-env to use sage’s gcc/g+
> On 3/10/2016, at 09:33, François Bissey
> wrote:
>
>> linbox
>
> No news from upstream at
> https://github.com/linbox-team/linbox/issues/39
> contributions welome.
Well as it turns out the problem is only in the interface with
fplll which we are going to disable in the next fplll upgrade.
W
Does the ntl failure look like anything reported at
https://trac.sagemath.org/ticket/20779 ?
François
> On 1/10/2016, at 14:52, Travis Scrimshaw wrote:
>
> Perhaps this is from the same error as stack overflow post? I remember we had
> to have something with '-march=native' (on OSX?) in the p
A fair question. I cannot remember the folder from the top of my head
but I have debugged that problem several time. First counting 35
blocks may not get you the right one, unless you are building
serially.
You should try to locate it under
local/share/doc/sage/inventory/en/reference/plot3d/sage/pl
I don’t know about debian based distro specifically but installing clang
shouldn’t remove gcc, they are orthogonal to each other.
When you try building a specific package try
CC=clang CXX=clang++ ./sage -f symmetrica
for example. Yes there is a possibility of your
sage install breaking after that.
Reanimating https://trac.sagemath.org/ticket/12426
There is a ticket for symmetrica, if you still want to do it, I’d rather you
fix the code with a patch than with a compilation flags as is suggested in
#12439.
François
> On 17/09/2016, at 15:53, Francois Bissey
> wrote:
>
> I
1 - 100 of 653 matches
Mail list logo
