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 trying to compress it with tar.
I've done a make clean, and I am recompiling without setting any environmental variables. Hopefully everything goes according to plan this time. I don't have any empirical evidence that icc is faster; it's just the general message that I got when I googled. I guess I should compile python using icc and gcc and run a computationally intensive script that I've wrote for a homework project some time ago. Thanks, David On Jan 12, 11:32 pm, mabshoff <mabsh...@googlemail.com> wrote: > 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 I don't have any empirical evidence that icc is faster; it's just the general message that I got when I googled. I guess I should compile python using icc and gcc and run a computationally intensive script that I've wrote for a homework project some time ago. Thanks, David On Jan 12, 11:32 pm, mabshoff <mabsh...@googlemail.com> wrote: > 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 > tohttp://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 I don't have any empirical evidence that icc is faster; it's just the general message that I got when I googled. I guess I should compile python using icc and gcc and run a computationally intensive script that I've wrote for a homework project some time ago. Thanks, David On Jan 12, 11:32 pm, mabshoff <mabsh...@googlemail.com> wrote: > 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 I don't have any empirical evidence that icc is faster; it's just the general message that I got when I googled. I guess I should compile python using icc and gcc and run a computationally intensive script that I've wrote for a homework project some time ago. Thanks, David On Jan 12, 11:32 pm, mabshoff <mabsh...@googlemail.com> wrote: > 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 > tohttp://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, > > Michaeltohttp://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 > > 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, > > Michaeltohttp://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 -~----------~----~----~----~------~----~------~--~---
