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 abou
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 wrote:
> found libstdc++.so.6 at /usr/local/lib64/libstdc++.so.6
This email
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
/home/jm58660/r-compile-test/sage-6.3/local/var/tmp/sage/build/r-3.1.1.p0/src/src/mai
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 wrote:
> 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
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
sa
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
"sage
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 -Wl,--exp
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
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 local/lib
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
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 wrote:
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 => (0x
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 =>
/home/jm58660/r-compile-test/sage-6.3/local/lib/lib
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 lib
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 us
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.
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 removin
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 do
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 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 -a
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 64
21 matches
Mail list logo
