On Wed, Feb 5, 2014 at 7:32 PM, John H Palmieri wrote:
> On Wednesday, February 5, 2014 4:33:58 PM UTC-8, David Roe wrote:
>>
>> I recently upgraded OS X and now run into trouble building Sage. XCode
>> displays the version number as Version 5.0.2 (5A3005).
>>
>
> Maybe see http://trac.sagemath.
On Tuesday, February 4, 2014 12:49:15 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2014-02-04 09:20, Anne Schilling wrote:
> > but it keeps reappearing.
> What you mean with this?
>
How can I tell make not to install semigroupe any longer then?
Anyway, I did
export SAGE_PORT='yes'
and now I can at
On Wednesday, February 5, 2014 4:33:58 PM UTC-8, David Roe wrote:
>
> I recently upgraded OS X and now run into trouble building Sage. XCode
> displays the version number as Version 5.0.2 (5A3005).
>
Maybe see http://trac.sagemath.org/ticket/15783? That is, after upgrading
Xcode, you need to
Can you start a sage shell(./sage -sh from the root directory of the tarball)?
If so start one and give the output of
ldd -r /home/sbh/SW/Sage6.1.1/sage-6.1.1/local/lib/libgsl.so.0
and
readelf -d /home/sbh/SW/Sage6.1.1/sage-6.1.1/local/lib/libgsl.so.0
Also do you have libclas.so.* in local/lib?
F
I recently upgraded OS X and now run into trouble building Sage. XCode
displays the version number as Version 5.0.2 (5A3005).
When I try "make build" in my existing Sage (built before the upgrade), I
get the following error:
checking for C compiler default output file name...
configure: error: C
Hello, after installing all prerequisites and updating, I downloaded the
latest Sage source code, sage-6.1.1.tar.gz. After unpacking all I did was
type
export SAGE64=yes
and then I just typed
make.
My laptop is a MacBook Pro (4,1) running Ubuntu 12.04LTS, 3.8GiB, Intel
Core 2 Duo CPU T8300
Hi Charles,
I have the same error - when installing Sage 6.1.1 source Did you ever
find a solution for it? (I couldn't see that you did by these emails...)
Thank you
Brett
On Thursday, December 19, 2013 7:18:22 PM UTC-7, Charles Greathouse wrote:
>
> I tried that now with the same results:
Hi, I'm once again working on applying Sage for the Google Summer of Code
programme.
Besides the application itself, we need a nice list of project ideas.
Students will use it to get ideas for what to write more detailed proposals
and also have ways to contact mentors to figure out the details.
On Wednesday, February 5, 2014 1:54:56 PM UTC, Thierry
(sage-googlesucks@xxx) wrote:
>
> - It is still possible to use/develop Sage without any problem after
> such a strip ?
> - Are some Sage debugging tool that need unstripped binaries ?
>
Clearly segfaults are going to be a lot less usefu
On Tuesday, February 4, 2014 11:34:26 AM UTC-5, Volker Braun wrote:
>
> I don't know why its not working for you, but what is failing is the
> following autoconf check:
>
> AC_CONFIG_SRCDIR([src/pycrypto_compat.h])
>
>
> My guess would be that you have some wonky environment variables
> pre-
On Wednesday, February 5, 2014 2:54:56 PM UTC+1, Thierry
(sage-googlesucks@xxx) wrote:
>
> On Tue, Feb 04, 2014 at 12:57:04PM -0800, William Stein wrote:
> > It would be cool if there were a make target that did all of this...,
> > e.g., "make cache-clean" since it is not at clear from the nam
On Tue, Feb 04, 2014 at 12:57:04PM -0800, William Stein wrote:
> It would be cool if there were a make target that did all of this...,
> e.g., "make cache-clean" since it is not at clear from the name that
> "upstream" is a cache directory that can be safely deleted, especially
> given that in the
Le 05/02/2014 11:48, Jean-Pierre Flori a écrit :
> If we're going to support ARM, should we only support hard floats?
> That seems sensible to me and would simplify pkgs install scripts (let's
> say GCC and ATLAS at least).
All bdist pkg I made in the last years have been with hard float.
Which
Arm VFP is an option that ARM licensees can include in their core or not,
so its not that easy. Though it is by now very common. Rasberry Pi has it.
On Wednesday, February 5, 2014 11:20:42 AM UTC, mmarco wrote:
>
> All recent (i.e. in the last, 2? years) arm processors have hard float
> support
All recent (i.e. in the last, 2? years) arm processors have hard float
support, right? In that case i say it is not a bad idea to not support soft
float, since it only affects old hardware.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsu
Sounds good to me. We are writing a math software, after all. And it
doesn't look like we are going to have a soft-float buildbot, so it won't
work even if we say that we support it.
On Wednesday, February 5, 2014 10:48:10 AM UTC, Jean-Pierre Flori wrote:
>
> If we're going to support ARM, shoul
Easy fix at
http://trac.sagemath.org/ticket/15785
(needs review)
--
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 post
Dear all,
If we're going to support ARM, should we only support hard floats?
That seems sensible to me and would simplify pkgs install scripts (let's
say GCC and ATLAS at least).
Best,
JP
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsub
18 matches
Mail list logo
