I have trouble compiling sage on my linux box which is as follow:
x86 (amd athlon - definitely not amd64)
distro is gentoo up to date as of last week. kernel 2.6.23, glibc
2.6.1
gcc-4.2.2, binutils-2.18.
The problem I have is in the compilation of sage itself more precisely
libcsage.
Here is the last message:
sage: Building and installing modified SAGE library files.
I poked around a bit and the problem is not with pari. The problem
is the parameter "-no_archive". My version of ld from binutils-2.18
doesn't
support such an option. In fact if it did, it should be --no_archive
as it is
the option can be interpreted as -n -o _archive and if I try to issue
it
again I end up with a file called _archive and a message about
creating an
archive containing DT_TEXTREL symbols.
Removing the -no_archive gives a normal result. Unfortunately I don't
know how
to resume the compilation process correctly from there as scons behave
very
differently from make.
I don't where to patch things so that it doesn't happen in the first
place. I
cannot find anything about this parameter in the SConstruct file or
spkg-install. I don't know where to look from there.
Things did go normally with sage 2.8.12 the first I compiled, I first
had the
problem trying to compile 2.8.15 and ever since. I didn't try 2.8.13.
or .14.
On Dec 28, 9:47 am, Francois <fbis...@slingshot.co.nz> wrote:
> Hi all,
> I have trouble compiling sage on my linux box which is as follow:
> x86 (amd athlon - definitely not amd64)
> distro is gentoo up to date as of last week. kernel 2.6.23, glibc
> 2.6.1
> gcc-4.2.2, binutils-2.18.
> The problem I have is in the compilation of sage itself more precisely
> libcsage.
> Here is the last message:
> sage: Building and installing modified SAGE library files.
> I poked around a bit and the problem is not with pari. The problem
> is the parameter "-no_archive". My version of ld from binutils-2.18
> doesn't
> support such an option. In fact if it did, it should be --no_archive
> as it is
> the option can be interpreted as -n -o _archive and if I try to issue
> it
> again I end up with a file called _archive and a message about
> creating an
> archive containing DT_TEXTREL symbols.
> Removing the -no_archive gives a normal result. Unfortunately I don't
> know how
> to resume the compilation process correctly from there as scons behave
> very
> differently from make.
> I don't where to patch things so that it doesn't happen in the first
> place. I
> cannot find anything about this parameter in the SConstruct file or
> spkg-install. I don't know where to look from there.
cd into devel/sage and execute "sage -b". That should continue the
build process.
> Things did go normally with sage 2.8.12 the first I compiled, I first
> had the
> problem trying to compile 2.8.15 and ever since. I didn't try 2.8.13.
> or .14.
> Any idea?
Thanks for the report. I will be looking into this.
> I poked around a bit and the problem is not with pari. The problem
> is the parameter "-no_archive". My version of ld from binutils-2.18
> doesn't
> support such an option. In fact if it did, it should be --no_archive
> as it is
> the option can be interpreted as -n -o _archive and if I try to issue
> it
> again I end up with a file called _archive and a message about
> creating an
> archive containing DT_TEXTREL symbols.
> Removing the -no_archive gives a normal result. Unfortunately I don't
> know how
> to resume the compilation process correctly from there as scons behave
> very
> differently from make.
> I don't where to patch things so that it doesn't happen in the first
> place. I
> cannot find anything about this parameter in the SConstruct file or
> spkg-install. I don't know where to look from there.
> Things did go normally with sage 2.8.12 the first I compiled, I first
> had the
> problem trying to compile 2.8.15 and ever since. I didn't try 2.8.13.
> or .14.
> Any idea?
I did poke around and there is no place in Sage that sets that flag.
Even a grep -r over a complete from source install does not yield any
hits. Since we import the current ENV into SCons is there any chance
it is in your ENV?
I think I found my problem. A little googling actually helped with
this link:
http://bugs.archlinux.org/task/6864 I did some experiments with the intel _fortran_ compiler (not even the
C compiler)
and I still have it on my system.
Since the intel compiler doesn't compile my lattice QCD code correctly
anyway
I will remove it and try again.
I am busy for the next few hours so I will do that a bit latter.
On Dec 28, 8:36 pm, Francois <fbis...@slingshot.co.nz> wrote:
> Hello Michael,
Hello Francois,
> I think I found my problem. A little googling actually helped with
> this link:http://bugs.archlinux.org/task/6864 > I did some experiments with the intel _fortran_ compiler (not even the
> C compiler)
> and I still have it on my system.
> Since the intel compiler doesn't compile my lattice QCD code correctly
> anyway
> I will remove it and try again.
> I am busy for the next few hours so I will do that a bit latter.
This is actually something we can prevent on our end by forcing SCons
to use the GNU compilers instead of the Intel ones in case they are
present. I had to fix similar issues on Solaris when Sun's compilers
were installed and SCons picked those over gcc. Thanks for tracking
this down. This is now
On Sat, 29 Dec 2007, mabshoff wrote: > On Dec 28, 8:36 pm, Francois <fbis...@slingshot.co.nz> wrote: > > Hello Michael,
> Hello Francois,
> > I think I found my problem. A little googling actually helped with > > this link:http://bugs.archlinux.org/task/6864 > > I did some experiments with the intel _fortran_ compiler (not even the > > C compiler) > > and I still have it on my system. > > Since the intel compiler doesn't compile my lattice QCD code correctly > > anyway > > I will remove it and try again. > > I am busy for the next few hours so I will do that a bit latter.
> This is actually something we can prevent on our end by forcing SCons > to use the GNU compilers instead of the Intel ones in case they are > present. I had to fix similar issues on Solaris when Sun's compilers > were installed and SCons picked those over gcc. Thanks for tracking > this down. This is now
