FWIW, upgradeing 8.2.beta3 to 8.2.beta5 gave the following results : :
-
on Debian testing running on Core i7 + 16 GB RAM, 8.2.beta5 passes
ptestlong with no failures whatsoever ;
-
On Cygwin64 running under Windows 7, 8.2beta5 passes testlong with one
reproducible
Hi,
Le vendredi 9 février 2018 09:25:28 UTC+1, Volker Braun a écrit :
>
> As always, you can get the latest beta version from the "develop" git
> branch. Alternatively, the self-contained source tarball is at
> http://www.sagemath.org/download-latest.html
>
>
On Ubuntu 16.04 running on Xeon
Thanks there was exactly what I was after - or almost
CLANG_DEFAULT_RTLIB
which may be needed for https://trac.sagemath.org/ticket/24712
> On 12/02/2018, at 21:22, Ralf Stephan wrote:
>
>
https://stackoverflow.com/questions/19901128/enable-libc-libcxx-by-default-when-using-clang
On Mon, Feb 12, 2018 at 9:16 AM François Bissey
wrote:
>
>
> > On 12/02/2018, at 20:06, Ralf Stephan wrote:
> >
> > Finally here is the recommended set of flags
> On 12/02/2018, at 20:06, Ralf Stephan wrote:
>
> Finally here is the recommended set of flags for clang on Linux:
>
> export CC="clang"
> export CXX="clang++"
> export CLANG_DEFAULT_CXX_STDLIB="libc++"
>
Where did you find about this variable? I’d like to know if there
make ptestlong passes on OpenSuSE 42.3 with clang-4.0.1 on top of #24696
with only the usual failures in R and that one reported in #21828.
On Mon, Feb 12, 2018 at 8:06 AM Ralf Stephan wrote:
> Finally here is the recommended set of flags for clang on Linux:
>
> export
Finally here is the recommended set of flags for clang on Linux:
export CC="clang"
export CXX="clang++"
export CLANG_DEFAULT_CXX_STDLIB="libc++"
Thanks to François for the hint. You'll need #24696 if giac doesn't
install, which seems to occur with clang < 5.
Best,
On Sun, Feb 11, 2018 at 5:53
See https://trac.sagemath.org/ticket/24701#comment:5 for the current state
of clang on Linux.
On Sun, Feb 11, 2018 at 3:39 PM Ralf Stephan wrote:
> Another bug uncovered. With CXXFLAGS='stdlib=libc++' scipy build fails
> with, of all things
> gfortran: error: unrecognized
Another bug uncovered. With CXXFLAGS='stdlib=libc++' scipy build fails
with, of all things
gfortran: error: unrecognized command line option '--stdlib=libc++'
Huh?
On Sun, Feb 11, 2018 at 11:40 AM Simon King wrote:
> Hi!
>
> On 2018-02-11, Ralf Stephan
Hi!
On 2018-02-11, Ralf Stephan wrote:
> Update with clang on Linux: sagelib ignores the --stdlib in CXX (#24705)
> and fpylll apparently ignores the --stdlib in CXX and if you give it in the
> CXXFLAGS it uses it only for C not C++ (#24707). So the former is a build
>
Hi François,
On 2018-02-11, François Bissey wrote:
> It looks like you may have to provide the include path to __cxxabi_config.h.
> I don’t know where ubuntu installs it. On Gentoo libcxx is configured at build
> time with the right location with the “USE” variable I
> On 11/02/2018, at 10:36, Simon King wrote:
>
>>
>> Ubuntu is probably the most used distro if someone can wipe up some
>> instructions
>> on what to install that would help greatly.
>
> Well, so far I was installing clang, clang-dev and libc++abi-dev. The
> latter
On Saturday, February 10, 2018 at 2:09:58 PM UTC, Ralf Stephan wrote:
>
> Also clang-5.0.0 cannot compile ppl. clang-3.8 and 4.0.1 are fine.
> https://trac.sagemath.org/ticket/24704
>
I think I reported this on PPL bug tracker some time ago...
>
>
> On Sat, Feb 10, 2018 at 2:52 PM Ralf
Hi François,
On 2018-02-10, François Bissey wrote:
> * if you switch from clang+libstdc++ to clang+libc++ (or libcxx depending on
> your distro)
How can I find out which one I have to use? In all my failing attempts,
I tried clang+libc++.
> Ubuntu is probably the most
I am sorry to have cause everyone who wanted to try it on linux so much
grief.
To summarise
* you need to build from scratch
* clang using libstdc++ from gcc appears to have problems - at the moment
I don’t know if it is just because the gcc in question is too old or that’s
a no go.
* if you
In the failing compilation, we have
clang++ --stdlib=libc++ [which is what we want]
... -std=c++11 [which comes from brial]
... -c BlockDegLexOrder.cc -fPIC -DPIC -o .libs/BlockDegLexOrder.o
And the error is then
/usr/include/c++/v1/cxxabi.h:21:10: fatal error: '__cxxabi_config.h'
Hi!
After installation of clang-dev, I tried again, but alas, brial failed
to build again.
Log is at
http://users.minet.uni-jena.de/cohomology/logs/brial-1.0.1.p2.log
So, I am giving up on it for now.
Best regards,
Simon
--
You received this message because you are subscribed to the Google
Dear John,
On 2018-02-10, John Cremona wrote:
> I installed clang on my ubuntu laptop. I use synaptic ( a front-end for
> apt & co) for installing stuff as it's easier to search.
Thanks a lot!
When searching for clang-devel in synaptic, I was pointed to
libclang-dev
I installed clang on my ubuntu laptop. I use synaptic ( a front-end for
apt & co) for installing stuff as it's easier to search. There's a package
"clang" and I have clang-3.8 installed as well as libclang-common-3.8-dev
(and there are others like tthat with 3.8 replaced by other versions), also
On 2018-02-10, Simon King wrote:
> I'll try to search for "clang-devel ubuntu".
No real success, except for some very complicated procedures
given at
https://askubuntu.com/questions/309786/llvm-and-clang-installation-on-ubuntu
and lots of stuff that isn't mentioning
Hi Ralf,
On 2018-02-10, Ralf Stephan wrote:
> You're missing a devel system package. I have it in clang-devel and
> libc++-devel.
I have libc++-devel (because it seems to be the only "libc++" available
for ubuntu). But clang-devel isn't known to apt-get.
I'll try to search
You're missing a devel system package. I have it in clang-devel and
libc++-devel.
On Sat, Feb 10, 2018 at 4:41 PM Simon King wrote:
> On 2018-02-10, Ralf Stephan wrote:
> > The linking error with --stdlib=libc++ persists. It appears ntl_ZZ.so is
> >
On 2018-02-10, Ralf Stephan wrote:
> The linking error with --stdlib=libc++ persists. It appears ntl_ZZ.so is
> built with both libstdc++ and libc++:
At least while building, ntl did not complain, see
http://users.minet.uni-jena.de/cohomology/logs/ntl-10.3.0.log
However,
The linking error with --stdlib=libc++ persists. It appears ntl_ZZ.so is
built with both libstdc++ and libc++:
ralf@ark:~/sage/pynac> ldd
/home/ralf/sage/local/lib/python2.7/site-packages/sage/libs/ntl/ntl_ZZ.so
linux-vdso.so.1 (0x7ffc8f3f1000)
libntl.so.33 =>
Welcome to the bleeding edge. I'm afraid it won't work without
--stdlib=libc++. Also with that I get a linking error:
Done cleaning.
Traceback (most recent call last):
File "/home/ralf/sage/src/bin/sage-eval", line 4, in
from sage.all import *
File
On 2018-02-10, Ralf Stephan wrote:
> Also clang-5.0.0 cannot compile ppl. clang-3.8 and 4.0.1 are fine.
> https://trac.sagemath.org/ticket/24704
According to my log, ppl-1.2 was built fine. But I guess that's because
I have clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Hi Ralf,
On 2018-02-10, Ralf Stephan wrote:
> Simon do you have libc++ system-installed and given CXX='clang++
> --stdlib=libc++' ?
How would I check whether I have libc++ installed? Resp. how would I
install it? sudo apt-get install libc++ gives loads of errors.
Best
Hi Ralf,
On 2018-02-10, Ralf Stephan wrote:
> Simon do you have libc++ system-installed and given CXX='clang++
> --stdlib=libc++' ?
No, I followed the previous advice to give CC=clan CXX=clan++.
Does that mean I should make distclean and start again from scratch?
Best
Simon do you have libc++ system-installed and given CXX='clang++
--stdlib=libc++' ?
On Sat, Feb 10, 2018 at 1:15 PM Simon King wrote:
> On 2018-02-10, Simon King wrote:
> > On 2018-02-10, Simon King wrote:
> >> Hi
On 2018-02-10, Simon King wrote:
> On 2018-02-10, Simon King wrote:
>> Hi François,
>>
>> On 2018-02-10, François Bissey wrote:
>>> I’d recommend to work on a separate clone. It is what I have done
>>> on my Gentoo linux box.
> On 11/02/2018, at 00:02, Simon King wrote:
>
>> s is what I did now. It is still in the process of building.
>
> While it was building, I noticed lines such as
> [python_openid-2.2.5.p0] Found candidate GCC installation:
> /usr/bin/../lib/gcc/i686-linux-gnu/5.4.0
Hi Ralf,
On 2018-02-10, Ralf Stephan wrote:
> FWIW for me as Pynac dev clang has far superior diagnostics and refactoring
> tools. From other programs I can confirm a speedup of compiled source of at
> least 5%.
Interesting. In threads from 2013, I also found that clang had
> On 10/02/2018, at 23:49, Simon King wrote:
>
> Hi François,
>
> On 2018-02-10, François Bissey wrote:
>> I’d recommend to work on a separate clone. It is what I have done
>> on my Gentoo linux box.
>
> This is what I did now. It is still in
On 2018-02-10, Simon King wrote:
> Hi François,
>
> On 2018-02-10, François Bissey wrote:
>> I’d recommend to work on a separate clone. It is what I have done
>> on my Gentoo linux box.
>
> This is what I did now. It is still in the process of
Hi François,
On 2018-02-10, François Bissey wrote:
> I’d recommend to work on a separate clone. It is what I have done
> on my Gentoo linux box.
This is what I did now. It is still in the process of building.
Will the SageMath installation recall that it was installed
> On 10/02/2018, at 22:02, Simon King wrote:
>
> On 2018-02-10, François Bissey wrote:
>> I’d recommend to work on a separate clone. It is what I have done
>> on my Gentoo linux box. I don’t know the state of clang on ubuntu
>> but it is better to
FWIW for me as Pynac dev clang has far superior diagnostics and refactoring
tools. From other programs I can confirm a speedup of compiled source of at
least 5%.
On Sat, Feb 10, 2018 at 9:55 AM François Bissey
wrote:
>
>
> > On 10/02/2018, at 21:44, Simon King
> On 10/02/2018, at 21:25, Simon King wrote:
>
> Here are reports that with clang things won't work in different ways
> (e.g., IIUC, segfaults in linbox on openSuse). Does that mean clang is
> buggy resp. not mature enough, or does that mean clang uncovers real
> bugs
Hi,
I'd like to get some information.
On 2018-02-09, François Bissey wrote:
>> On 9/02/2018, at 23:03, Ralf Stephan wrote:
>>
>> So how to use clang on Linux?
*Why* to use clang in the first place? I am not familiar with it, so I'd
appreciate if you
This is way above my understanding of "make" matters. So help from Erik or
Jeroen or whoever is knowledgeable in this kind of things, is required.
Le vendredi 9 février 2018 21:24:34 UTC+1, Volker Braun a écrit :
>
> Can you first set up a makefile target that is supposed to be tested? E.g.
>
Can you first set up a makefile target that is supposed to be tested? E.g.
"make test-python3" builds with py3 and eventually gets extended to test
things that already work?
On Friday, February 9, 2018 at 9:15:04 PM UTC+1, fchap...@gmail.com wrote:
>
> Volker, it would be great (and I would
Volker, it would be great (and I would appreciate) if you could set up a
buildbot that checks that sage builds with python3. One can not yet say
that vanilla-sage builds and starts with "export SAGE_PYTHON3=yes", but at
least it builds (since some time already). Starting is another matter, but
On 2018-02-09 17:55, fchapot...@gmail.com wrote:
I have a build failure in subprocess32 on a python3 build (using export
SAGE_PYTHON3=yes)
Fixed in https://trac.sagemath.org/ticket/24650
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To
OK, that’s a slightly different issue. I didn’t think that would be a problem
but this
package shouldn’t be needed with python3.2+ since it is a backport of
functionality for
older python. So it would be best not to install it with python3.
> On 10/02/2018, at 05:55, fchapot...@gmail.com wrote:
I have a build failure in subprocess32 on a python3 build (using export
SAGE_PYTHON3=yes)
[subprocess32-3.2.7] Found local metadata for subprocess32-3.2.7
[subprocess32-3.2.7] Attempting to download package
subprocess32-3.2.7.tar.gz from mirrors
[subprocess32-3.2.7]
On 2018-02-09 12:02, François Bissey wrote:
We have seen an instance of that problem during review
but we thought it was fixed.
That was a different issue. While the error message was the same, the
underlying reason was different.
--
You received this message because you are subscribed to
I think I understand why this might happen:
https://trac.sagemath.org/ticket/24694
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I sent something at your lri adress.
Le vendredi 9 février 2018 13:52:24 UTC+1, Jeroen Demeyer a écrit :
>
> On 2018-02-09 11:56, fchap...@gmail.com wrote:
> > An incremental build from previous beta fails on gfortran :
>
> Please do
>
> touch configure.ac && make build
>
> and send me the
On 2018-02-09 11:56, fchapot...@gmail.com wrote:
An incremental build from previous beta fails on gfortran :
Please do
touch configure.ac && make build
and send me the full output.
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To
I did a make distclean and make. Everything built smoothly.
Le vendredi 9 février 2018 12:10:40 UTC+1, François Bissey a écrit :
>
> Actually if you have the autotools packages installed (from the system or
> sage)
> can you try
> autoreconf -i
> then re-run configure and see if that fix it.
Actually if you have the autotools packages installed (from the system or sage)
can you try
autoreconf -i
then re-run configure and see if that fix it.
> On 10/02/2018, at 00:02, François Bissey wrote:
>
> Which version of ubuntu? We have seen an instance of that problem
ubuntu 17.10. There is also at least one patchbot having the same issue, see
https://patchbot.sagemath.org/ticket/0/
Le vendredi 9 février 2018 12:02:28 UTC+1, François Bissey a écrit :
>
> Which version of ubuntu? We have seen an instance of that problem during
> review
> but we thought it
Which version of ubuntu? We have seen an instance of that problem during review
but we thought it was fixed. OK, there was something nagging me but it looked
fixed on the patchbot.
> On 9/02/2018, at 23:56, fchapot...@gmail.com wrote:
>
> An incremental build from previous beta fails on
An incremental build from previous beta fails on gfortran :
[gfortran-7.2.0] Found local metadata for gfortran-7.2.0
[gfortran-7.2.0] Using cached file
/home/chapoton/sage/upstream/gcc-7.2.0.tar.xz
[gfortran-7.2.0] gfortran-7.2.0
[gfortran-7.2.0]
54 matches
Mail list logo