On Jan 12, 8:17 pm, DavidS <davidshi...@gmail.com> 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:
<SNIP>
> /usr/bin/ld: /home/katana/builds/sage-3.2.2/local/lib/libpari.a
> (arith1.o): relocation R_X86_64_32 against `a local symbol' can not be
> used when making a shared object; recompile with -
> fPIC
> /home/katana/builds/sage-3.2.2/local/lib/libpari.a: could not read
> symbols: Badvalue
> collect2: ld returned 1 exit status
> make[3]: *** [libjcntl.so] Error 1
> make[3]: Leaving directory `/home/katana/builds/sage-3.2.2/spkg/build/
> eclib-20080310.p7/src/procs'
> make[2]: *** [so] Error 2
> make[2]: Leaving directory `/home/katana/builds/sage-3.2.2/spkg/build/
> eclib-20080310.p7/src'
> Error building cremona shared libraries
Strange, since eclib should be linking against the dynamic libpari.so
anyway. Could you bzip2 up your log and post a link to it somewhere so
I can take a look. Depending on why the dynamic lib isn't picked up I
will either fix pari and/or eclib since I am planning to update both
in Sage 3.3.
<SNIP>
> This error had been reported in Jan 2008, but the person who reported
> the issue never followed up...
>
> Should I clean everything and rebuilt after setting CFLAGS and
> CXXFLAGS = -fPIC?
That won't work.
> Most libraries that have been built all seem to have been built using
> the -fPIC flag. Is it safe to set this flag globally?
There is the concern about performance regressions, but according to
http://bugs.mysql.com/bug.php?id=18091
[quote]
Regarding this comment from Kent:
> As position independent code (PIC) is slower on some
> platforms we need to make sure only the client
> code is compiled with PIC flags. The client library is
> not performance critical in the same way as the server.
I believe it is a well known fact that on x86_64 (AMD64) platform the
PIC code does not
cause performance degradation. Can we at least have x86_64 binaries
compiled with -fPIC
flag in the next release please?
[end quote]
I have been unable to find such information independently of that
blurb.
> Another issue that I've been having is that I would like to build each
> package separately. (So I wouldn't have to rebuild the whole thing
> when an error like this occurs...) Is there a way of doing this? I
> wanted to use Intel compilers, but they seemed to fail with some of
> the packages (e.g. gmp-fake*, NTL, perhaps more?), so I would like
> compile whatever I can with Intel, and compile the rest with GNU
> compilers.
Building with the Intel compiler is currently not supported and I
doubt it will give you better performance, especially on x86-64. In
the not too distant future we might add support for non-gcc, but so
far there isn't any convenient way to do it. There are a couple
tickets to deal with setting env variables to select compilers, but
non of that is implemented yet, but I do have a long list of things to
fix in the build system, so I will get to it. Mixing and matching
packages compiled with icc in C++ mode and g++ is not something I
would want to do anyway. At least I wouldn't want to debut it :)
Do you have any empirical evidence that icc is faster for any real
code, i.e. is python compiled with icc faster by a noticeable margin?
> Thanks
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
