On Feb 4, 1:26 pm, Alexander Dreyer
wrote:
> Hi,> Strange to me that it's only polybori which wouldn't build, and that I
>
> [...]
> Maybe polybori is the only package (al least in sage), which uses
> scons and sonames.
Yes, the only other lib we build is libcsage and we don't use sonames
for
On Feb 4, 1:16 pm, Alexander Dreyer
wrote:
> Hi!> 'LINK': '$SMARTLINK',
> > 'LINKCOM': '$LINK -o $TARGET $LINKFLAGS $SOURCES $_LIBDIRFLAGS
> > $_LIBFLAGS',
>
> > and like the likely culprit IMHO.
>
> yeah, and it seems, that the scons people are not aware of this issue
> with the Intel comp
On Feb 4, 1:15 pm, dannychrastina wrote:
> Hi,
> > and like the likely culprit IMHO.
>
> Strange to me that it's only polybori which wouldn't build, and that I
> only ever saw gcc an g++ being called, and sage comes with its own
> fortran compiler so why would i go anywhere near ifort, but I
Hi,
> Strange to me that it's only polybori which wouldn't build, and that I
[...]
Maybe polybori is the only package (al least in sage), which uses
scons and sonames. Other packages I know, either do not make use of
the soname or use libtool (the latter ist unfortunately not supported
by scons).
Hi!
> 'LINK': '$SMARTLINK',
> 'LINKCOM': '$LINK -o $TARGET $LINKFLAGS $SOURCES $_LIBDIRFLAGS
> $_LIBFLAGS',
>
> and like the likely culprit IMHO.
yeah, and it seems, that the scons people are not aware of this issue
with the Intel compiler: the (built-in) RPATHPREFIX is in the same
errorous fo
Hi!
> 'LINK': '$SMARTLINK',
> 'LINKCOM': '$LINK -o $TARGET $LINKFLAGS $SOURCES $_LIBDIRFLAGS
> $_LIBFLAGS',
>
> and like the likely culprit IMHO.
yeah, and it seems, that the scons people are not aware of this issue
with the Intel compiler: the (built-in) RPATHPREFIX is in the same
errorous fo
Hi,
On Feb 4, 9:18 pm, mabshoff wrote:
> On Feb 4, 12:07 pm, dannychrastina wrote:
> > On Feb 4, 8:13 pm, Alexander Dreyer
> > wrote:
> > > although the Intel-Compiler environment is not advised, I would also
> > > be interested in a dump of the scons environment, i.e. the output of
> > > the
On Feb 4, 12:07 pm, dannychrastina wrote:
> On Feb 4, 8:13 pm, Alexander Dreyer
Hi Danny,
> wrote:
> > Hi Danny,
> > although the Intel-Compiler environment is not advised, I would also
> > be interested in a dump of the scons environment, i.e. the output of
> > the following:
> > echo "prin
On Feb 4, 8:13 pm, Alexander Dreyer
wrote:
> Hi Danny,
> although the Intel-Compiler environment is not advised, I would also
> be interested in a dump of the scons environment, i.e. the output of
> the following:
> echo "print Environment().Dump()" > dummyscfile; scons -f dummyscfile;
> rm dummy
Hi Danny,
although the Intel-Compiler environment is not advised, I would also
be interested in a dump of the scons environment, i.e. the output of
the following:
echo "print Environment().Dump()" > dummyscfile; scons -f dummyscfile;
rm dummyscfile
This might help me to set the correct sonamepref
On Feb 4, 7:46 am, dannychrastina wrote:
> Hi,
Hi Danny,
> Athttp://www.triv.org.uk/~danny/sage/you should find the env dump
> and the compressed install log.
3 seconds looking at the env dump did confirm my suspicion. You do
have the Intel C/C++ compiler in $PATH. Can you set PATH not to
On Feb 3, 4:26 pm, mabshoff wrote:
> On Feb 3, 4:53 am, dannychrastina wrote:
>
>
>
> Hi,
>
> > Ok, so I extracted the .spkg of polybori (having worked out that it
> > was just a bzipped tarball), changed SConstruct (with sonameprefix as
> > '-Wl,-soname -Wl,'), and repackaged it, and it didn
On Feb 3, 4:53 am, dannychrastina wrote:
Hi,
> Ok, so I extracted the .spkg of polybori (having worked out that it
> was just a bzipped tarball), changed SConstruct (with sonameprefix as
> '-Wl,-soname -Wl,'), and repackaged it, and it didn't work:
>
> ld -o polybori/libpolybori-0.5.1.so.0.
On Feb 3, 9:36 am, Alexander Dreyer
wrote:
> > > Hi, I'm having the same error with 3.2.3 (on Gentoo x86_64). It seems
> > > to me that this '-Wl,-soname,libpolybori-0.5.0.so.0' is in the form in
> > > which options are given to the compiler in order to pass to the
> > > linker, but since this is
On Feb 3, 12:36 am, Alexander Dreyer
wrote:
Hi Alexander,
> Hi,> > Hi, I'm having the same error with 3.2.3 (on Gentoo x86_64). It seems
> > > to me that this '-Wl,-soname,libpolybori-0.5.0.so.0' is in the form in
> > > which options are given to the compiler in order to pass to the
> > > lin
On Feb 3, 12:34 am, dannychrastina wrote:
> On Feb 3, 2:13 am, mabshoff wrote:
> > * What binutils release are you running (i.e. ld --version)
>
> GNU ld (GNU Binutils) 2.18.
>
> I notice David (above) had the same problem using 2.19. Also, just for
> completeness,
I *very* much doubt tha
Hi,
> > Hi, I'm having the same error with 3.2.3 (on Gentoo x86_64). It seems
> > to me that this '-Wl,-soname,libpolybori-0.5.0.so.0' is in the form in
> > which options are given to the compiler in order to pass to the
> > linker, but since this is running the linker directly it should just
> >
On Feb 3, 2:13 am, mabshoff wrote:
> On Feb 2, 2:43 pm, dannychrastina wrote:
>
> > On Jan 14, 4:04 pm, mabshoff wrote:
>
> > > On Jan 13, 10:13 pm, DavidS wrote:
> > > > But further along the compilation, I got stuck here:
> > > > ld -opolybori/libpolybori-0.5.0.so.0.0.0 -shared -Wl,-
> > >
On Feb 2, 2:43 pm, dannychrastina wrote:
> On Jan 14, 4:04 pm, mabshoff wrote:
>
> > On Jan 13, 10:13 pm, DavidS wrote:
> > > But further along the compilation, I got stuck here:
> > > ld -opolybori/libpolybori-0.5.0.so.0.0.0 -shared -Wl,-
> > > soname,libpolybori-0.5.0.so.0 Cudd/obj/cuddObj.
On Jan 14, 4:04 pm, mabshoff wrote:
> On Jan 13, 10:13 pm, DavidS wrote:
> > But further along the compilation, I got stuck here:
> > ld -opolybori/libpolybori-0.5.0.so.0.0.0 -shared -Wl,-
> > soname,libpolybori-0.5.0.so.0 Cudd/obj/cuddObj.os Cudd/util/
> > state.os ..
> > ld: unrecognized
On Jan 13, 10:13 pm, DavidS wrote:
> Hi Michael,
Hi David,
> So the previous problem disappeared, but I ran into 2 more problems,
> one of which is still unresolved.
> It has been reported earlier that the fortran compiler that comes with
> sage does not work well with Archlinux. The work-aro
Hi Michael,
So the previous problem disappeared, but I ran into 2 more problems,
one of which is still unresolved.
It has been reported earlier that the fortran compiler that comes with
sage does not work well with Archlinux. The work-around the Archlinux
group used was to set 2 environmental var
On Jan 13, 6:29 pm, DavidS wrote:
> Hi Michael,
Hi David,
> I don't think libpari.so was ever built (I can only find the comments
> for libpari.a in install.log). Perhaps I fouled things up when I built
> the first few packages (including libpari.so) with icc and icpc. I had
> wanted to uploa
Hi Michael,
I don't think libpari.so was ever built (I can only find the comments
for libpari.a in install.log). Perhaps I fouled things up when I built
the first few packages (including libpari.so) with icc and icpc. I had
wanted to upload my log, but I managed to mess my install.log up while
tr
On Jan 12, 8:17 pm, DavidS wrote:
Hi David,
> I tried to build sage-3.2.2 using gcc/g++ 4.3.2 on an Archlinux 2.6.27
> x86_64.
>
> The build fails then it tries to link libpari.a, which had not been
> compiled with the -fPIC flag. The relevant part of the rror message:
> /usr/bin/ld: /home
25 matches
Mail list logo
