On Thu, 4 Sep 2014, Volker Braun wrote:
ls -al /lib /lib64
ls: cannot access /lib64 : No such file or directory
You don't have a 64-bit system, it seems.
What the hell... I have just mechanically copied output without thinkin.
I have 64-bit system where /lib64 is symlink to
The missing symbol is in libgfortran:
$ readelf -aW /usr/lib64/libgfortran.so.3 | grep
_gfortran_transfer_integer_write@@GFORTRAN_1.4
676: 000e1f40 5 FUNCGLOBAL DEFAULT 12
_gfortran_transfer_integer_write@@GFORTRAN_1.4
So it seems that we don't link libf77blas against
On Fri, 5 Sep 2014, Volker Braun wrote:
So it seems that we don't link libf77blas against libgfortran. Whats the output
of
sage -sh -c ldd local/lib/libf77blas.so
linux-vdso.so.1 = (0x7fffad3fe000)
libatlas.so.3 =
On Friday, September 5, 2014 11:42:21 AM UTC+2, Jori Mantysalo wrote:
On Fri, 5 Sep 2014, Volker Braun wrote:
So it seems that we don't link libf77blas against libgfortran. Whats the
output of
sage -sh -c ldd local/lib/libf77blas.so
linux-vdso.so.1 =
What is very curious is that you have a compilation error, yet you say
that setting LD_LIBRARY_PATH solve the problem. That variable
shouldn't influence compilation/linking, unlike LD_RUN_PATH or
LDFLAGS.
Are you using gold for linking?
François
On 5/09/2014, at 21:42, Jori Mantysalo
On Fri, 5 Sep 2014, Jean-Pierre Flori wrote:
Btw, I just installed a clean Fedora 20. At least yum install patch m4
is needed before compiling. Might be worth writing up somewhere the
packages that are needed to compile.
http://www.sagemath.org/doc/installation/source.html
The erroneous dependency on patch was fixed in #16794
On Friday, September 5, 2014 10:42:21 AM UTC+1, Jori Mantysalo wrote:
On Fri, 5 Sep 2014, Volker Braun wrote:
So it seems that we don't link libf77blas against libgfortran. Whats the
output of
sage -sh -c ldd
On Fri, 5 Sep 2014, Francois Bissey wrote:
What is very curious is that you have a compilation error, yet you say
that setting LD_LIBRARY_PATH solve the problem. That variable
shouldn't influence compilation/linking, unlike LD_RUN_PATH or
LDFLAGS.
Are you using gold for linking?
I have never
In
/home/jm58660/r-compile-test/sage-6.3/local/var/tmp/sage/build/r-3.1.1.p0/src/src/main
What does
gcc -std=gnu99 -Wl,--export-dynamic -fopenmp
-L/home/jm58660/r-compile-test/sage-6.3/local/lib/ -o R.bin Rmain.o
-L../../lib -lR -Wl,--verbose
says.
Furthermore, does
gcc -std=gnu99
On Friday, September 5, 2014 11:30:44 AM UTC+1, Jori Mantysalo wrote:
I have never needed to think about what linker I am using. If gold is
installed as a default on Fedora, then I am using it.
Its not.
--
You received this message because you are subscribed to the Google Groups
On Fri, 5 Sep 2014, Francois Bissey wrote:
In
/home/jm58660/r-compile-test/sage-6.3/local/var/tmp/sage/build/r-3.1.1.p0/src/src/main
What does
gcc -std=gnu99 -Wl,--export-dynamic -fopenmp
-L/home/jm58660/r-compile-test/sage-6.3/local/lib/ -o R.bin Rmain.o
-L../../lib -lR -Wl,--verbose
Sorry you should have started a sage shell first
/home/jm58660/r-compile-test/sage-6.3/sage -sh
On 5/09/2014, at 23:00, Jori Mantysalo jori.mantys...@uta.fi wrote:
On Fri, 5 Sep 2014, Francois Bissey wrote:
In
On Fri, 5 Sep 2014, Francois Bissey wrote:
Sorry you should have started a sage shell first
/home/jm58660/r-compile-test/sage-6.3/sage -sh
And then cd and gcc? Here:
(sage-sh) jm58660@localhost:sage-6.3$ cd
You appear to have bits of another gnu compiler in /usr/local. You
don't appear to have the binaries but some libs. Do you also have
libgfortran under /usr/local/lib64?
François
On 5/09/2014, at 23:14, Jori Mantysalo jori.mantys...@uta.fi wrote:
found libstdc++.so.6 at
On Fri, 5 Sep 2014, Francois Bissey wrote:
You appear to have bits of another gnu compiler in /usr/local. You
don't appear to have the binaries but some libs. Do you also have
libgfortran under /usr/local/lib64?
Yes. And of course /usr/local/* is checked before / and /usr. I have no
idea
On Wed, 3 Sep 2014, Volker Braun wrote:
Seems that Sage's version of libgfortran clashes with what ATLAS has
been compiled with. Try a make distclean make to build from a clean
slate if you haven't done so before. Also, are you compiling ATLAS or
using the system ATLAS?
I tried removing
On Thursday, September 4, 2014 1:35:21 PM UTC+1, Jori Mantysalo wrote:
ls -al /lib /lib64
ls: cannot access /lib64 : No such file or directory
You don't have a 64-bit system, it seems.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To
It works for me on Fedora 20 without doing anything like that. Can you post
the R build log and the output of:
cpp -print-search-dirs
ls -al /lib /lib64
cat /etc/fedora-release
On Wednesday, September 3, 2014 8:05:47 AM UTC+1, Jori Mantysalo wrote:
Usually ./configure make works on my
On Wed, 3 Sep 2014, Volker Braun wrote:
It works for me on Fedora 20 without doing anything like that. Can you post the
R build log
Here: http://www.sis.uta.fi/~jm58660/r-3.1.1.p0.log
cpp -print-search-dirsls -al /lib /lib64
I guess you mean -print-search-dirs. It also gives error from
Two separate commands:
cpp -print-search-dirs
ls -al /lib /lib64
In any case, /usr/lib/../lib64/ == /usr/lib64 is already in the library
search path so you don't have to specify it on the
command line.
On Wednesday, September 3, 2014 2:15:25 PM UTC+1, Jori Mantysalo wrote:
On Wed, 3 Sep
On Wednesday, September 3, 2014 2:15:25 PM UTC+1, Jori Mantysalo wrote:
Here: http://www.sis.uta.fi/~jm58660/r-3.1.1.p0.log
Seems that Sage's version of libgfortran clashes with what ATLAS has been
compiled with. Try a make distclean make to build from a clean slate
if you haven't done so
21 matches
Mail list logo
