JohnCremona
commented
14 years ago comment:43
It's at http://pari.math.u-bordeaux.fr/cgi-bin/pkgreport.cgi?pkg=pari (#1075)
Closed williamstein closed 14 years ago
JohnCremona
commented
14 years ago It's at http://pari.math.u-bordeaux.fr/cgi-bin/pkgreport.cgi?pkg=pari (#1075)
JohnCremona
commented
14 years ago Replying to @JohnCremona:
It's at http://pari.math.u-bordeaux.fr/cgi-bin/pkgreport.cgi?pkg=pari (#1075)
Karim Belabas writes:
Simpler symptom:
nffactor(polcyclo(21,y), x^2-y^7);
This is actually unrelated to #1070. It was due to an nf being replaced
by nf.pol --- because we use Trager's trick in that range instead of a
direct relative factorization, and don't need the nf data ---.
Unfortunately, a branch of the code later tried to acces nf.index, thus
accessing a random coefficient of the defining t_POL instead of the
relevant nf data.
Fixed in svn.
Cheers,
K.B.so we now have another reason for upgrading the source in the spkg.
williamstein
commented
14 years ago Please don't move stuff to sage-5.0. There will be a sage between sage-4.5 and sage-5.0, and that is what you should move the ticket to. Otherwise it could much more easily get lost.... I'll make such a roadmap entry now.
jdemeyer
commented
14 years ago Attachment: 9343_discrete_log.patch.gz
jdemeyer
commented
14 years ago I attached a small patch for integer discrete logarithms. Note that the result in the doctest has always been wrong, but will now be corrected (so this is really a bug in the current version of Sage).
williamstein
commented
14 years ago Replying to @jdemeyer:
I attached a small patch for integer discrete logarithms. Note that the result in the doctest has always been wrong, but will now be corrected (so this is really a bug in the current version of Sage).
Great work! I'm really glad we taught you Sage development last week!!!!
11d1fc49-71a1-44e1-869f-76be013245a0
commented
14 years ago Sorry to disrupt this little love-in here, but that bug has already been found (#9205) and fixed, and the patch has a positive review, and will probably be merged in the next alpha.
There are about a hundred patches with positive review waiting on trac, many of which have something to do with number fields (as a consequence of the big number theory Sage days at MSRI). I'm disappointed to realise that you folks haven't taken this into account, which will most likely mean that your work getting the number theory code to pass doctests with the new Pari version will be reduced to complete junk when all your patches fail to apply to the next alpha.
JohnCremona
commented
14 years ago No need to be quite so negative. Jeroen, I'm not sure why you thought that this ticket was the right place to add your patch anyway -- what does it have to do with the pari upgrade?
jdemeyer
commented
14 years ago Replying to @JohnCremona:
No need to be quite so negative. Jeroen, I'm not sure why you thought that this ticket was the right place to add your patch anyway -- what does it have to do with the pari upgrade?
It is related to the PARI upgrade because the new version of PARI fixes discrete logs (so, it fixes also #9205). Doing the upgrade of PARI made a doctest fail, because the "expected" result from the doctest was wrong.
jdemeyer
commented
14 years ago Regarding the issue of
RR(gp(exp(1)))or
ZZ(gp(1))This makes Sage hang but without using CPU time. So it does not go into an infinite loop, it literally does nothing.
williamstein
commented
14 years ago Replying to @loefflerd:
Sorry to disrupt this little love-in here, but that bug has already been found (#9205) and fixed, and the patch has a positive review, and will probably be merged in the next alpha.
We really need to release sage-4.5, so that somebody can get started with the next alpha (4.5.1).
There are about a hundred patches with positive review waiting on trac, many of which have something to do with number fields (as a consequence of the big number theory Sage days at MSRI). I'm disappointed to realise that you folks haven't taken this into account, which will most likely mean that your work getting the number theory code to pass doctests with the new Pari version will be reduced to complete junk when all your patches fail to apply to the next alpha.
That's pretty harsh. Anyway, the pari upgrade is higher priority, so in fact it will be the other way around.
William
williamstein
commented
14 years ago Replying to @jdemeyer:
Regarding the issue of
RR(gp(exp(1)))or
ZZ(gp(1))
When you use gp it is running the command in a subprocess. Thus you'll never see any (nontrivial) CPU time.
This makes Sage hang but without using CPU time. So it does not go into an infinite loop, it literally does nothing.
jdemeyer
commented
14 years ago I think I just had a small break-through:
The gp command now has the so-called "breakloop" on by default. This means the following: if Sage executes a command through the gp interface which gives errors, the following will be displayed in the pseudo-tty (invisible to the Sage user):
? 1/0
*** at top-level: 1/0
*** ^--
*** _/_: division by zero
*** Break loop: type 'break' to go back to GP
break>Now gp just waits for user input. Since that input will never come, it just sits there forever.
I have a temporary workaround for this: in the directory SAGE_ROOT/local/bin, move "gp" to "gp-real". Then create the following shell script called "gp":
!/bin/bash
mkdir -p $HOME/sage_debug
export HOME=$HOME/sage_debug
echo "breakloop = 0" >$HOME/.gprc
# Remove --fast option
exec $SAGE_ROOT/local/bin/gp-real --emacs --quiet --stacksize 100000000This changes $HOME and makes a .gprc file in it which disables the break loop. It then runs gp without --fast, so that the .gprc file is read.
JohnCremona
commented
14 years ago Attachment: 9343_extcode_dokchitser.patch.gz
Jeroen: I was surprised to see your dokchitser patch since I thought I was working on that -- and I have been in correspondence with Tim D all morning trying to sort out the use of global variables. So, does you patch sort out all those issues (as well as the easy defult() ones)? If so, I clearly have wasted a lot of time today. This example makes it clear how extremely important it is that people say clearly what tey are working on. And I DID say clearly that I was working on everythin the elliptic_curves directory, which includes all the code which calls the Dokchiter script.
On your other point, well spotted. But would it not be simpler to send to the gp process on initialization the command gp._eval_line('breakloop=0;') ?
Now I will go out and enjoy my Sunday, since my efforts seem to be not needed.
jdemeyer
commented
14 years ago Replying to @JohnCremona:
Jeroen: I was surprised to see your dokchitser patch since I thought I was working on that -- and I have been in correspondence with Tim D all morning trying to sort out the use of global variables. So, does you patch sort out all those issues (as well as the easy defult() ones)? If so, I clearly have wasted a lot of time today. This example makes it clear how extremely important it is that people say clearly what tey are working on. And I DID say clearly that I was working on everythin the elliptic_curves directory, which includes all the code which calls the Dokchiter script. Now I will go out and enjoy my Sunday, since my efforts seem to be not needed.
Well, I fixed the dokchitser script so it would pass some doctests in number_field.py. But my fixes are very trivial (it took me no more than 5 minutes), so maybe you are making more serious changes to the file. In that case, you can safely ignore my patch.
jdemeyer
commented
14 years ago Replying to @JohnCremona:
On your other point, well spotted. But would it not be simpler to send to the gp process on initialization the command gp._eval_line('breakloop=0;') ?
Certainly, yes. That's why I called my solution a "work-around". What you want to do is every time a gp process gets started, the first line should be
default(breakloop,0);But I don't know how to do this.
williamstein
commented
14 years ago But I don't know how to do this.
Look in interfaces/gp.py and/or expect.py.
jdemeyer
commented
14 years ago I will stop working on this for now (at least for the coming week), so I uploaded what I have done so far. There are still many things to be done, though.
One thing which I looked at but did not manage to fix was factorization of polynomials over number fields in sage/rings/polynomial/polynomial_element.pyx
jdemeyer
commented
14 years ago Attachment: 9343_number_field_part1.patch.gz
jdemeyer
commented
14 years ago Another PARI/GP bug found thanks to Sage: PARI bug 1076
jdemeyer
commented
14 years ago TODO: add more doctests for factoring polynomials over number fields. Various cases:
JohnCremona
commented
14 years ago Replying to @williamstein:
But I don't know how to do this.
Look in interfaces/gp.py and/or expect.py.
Sorted, I added one line (line 170) in sage/interfaces/gp.py which says
self._eval_line('default(breakloop,0);')to get the command run everytime a new gp instance is created. Now we get
sage: gp.eval('1/0')
' *** at top-level: 1/0\n *** ^--\n *** _/_: division by zero'(followed by a new sage: prompt) and also
RR(gp(exp(1)))
2.71828182845905
sage: with no problems.
JohnCremona
commented
14 years ago apply instead of previous extcode-dokchitser patch
JohnCremona
commented
14 years ago Attachment: 9343_extcode_dokchitser-1.patch.gz
I replaced Jeroen's 9343_extcode-dokchitser.patch with a new one which also fixes the test scripts in extcode/pari/dokchitser; and fixes one line in extcode/pari/simon/ellQ.gp which is all that is required for that set of scripts.
JohnCremona
commented
14 years ago Replying to @JohnCremona:
Jeroen: I was surprised to see your dokchitser patch since I thought I was working on that -- and I have been in correspondence with Tim D all morning trying to sort out the use of global variables. So, does you patch sort out all those issues (as well as the easy defult() ones)? If so, I clearly have wasted a lot of time today. This example makes it clear how extremely important it is that people say clearly what tey are working on. And I DID say clearly that I was working on everythin the elliptic_curves directory, which includes all the code which calls the Dokchiter script.
Apologies for this outburst. I did waste time, but only because of my inferior gp-script debugging skills. Thanks to Jeroen there is a much simpler fix for what was troubling me!
On your other point, well spotted. But would it not be simpler to send to the gp process on initialization the command gp._eval_line('breakloop=0;') ?
Now I will go out and enjoy my Sunday, since my efforts seem to be not needed.
JohnCremona
commented
14 years ago Replying to @jdemeyer:
Replying to @williamstein:
Replying to @JohnCremona:
I just noticed that the .p3.spkg compiles pari with flag -O1. Surely this is not a sensible choice?
Surely it was done on purpose, because with a bigger optimization flag PARI must have exhibited some bugs. The question is how/why/if this is still needed.
I always compile my own copy of PARI/GP with -O3 -fomit-frame-pointer -march=core2 using the latest gcc and that seems to work fine.
The answer is at #7092: because of a failure to build pari with gcc-4.4.1 as distributed by Fedora 11, on ALL Linux systems the OPTFLAG is set to -O1 instead of -O3. Is there not a way to detect that particular compiler-distro combination? Otherwise all Linux users suffer!
williamstein
commented
14 years ago Is there not a way to detect that particular compiler-distro combination? Otherwise all Linux users suffer!
It was a big mistake that #7092 got a positive review (from Jaap), and another mistake that the release manager (me) didn't reject that review. Anyway, thanks for tracking this down -- we should definitely make that -O1 hack only Fedora 11.
-- William
williamstein
commented
14 years ago Also, we don't have to support fedora 11 -- it's like 2 versions out of date, and we only claim to support the latest Linux versions, out of the box.
JohnCremona
commented
14 years ago fixes most doctests in elliptic_curves and interfaces/gp
JohnCremona
commented
14 years ago Attachment: trac_9343-elliptic-curve.patch.gz
trac_9343-elliptic-curve.patch + http://www.warwick.ac.uk/staff/J.E.Cremona/pari-2.4.3.svn.p4.spkg (which upgrades to svn 12533) do the following:
All in libs/ pass except some remaining issues in gen.pyx, mostly just fuzz but including one SIGSEGV
I thought this worth posting despite there still being issues in some of the files it touches.
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago I'm attaching a spkg-check file. I originally created #9518 to add the spkg-check, but John said to leave it, and let the changes be made as part of this ticket. When this ticket gets closed, so can #9518
Note there is an error in spkg-install on the first line, which displays as:
B1;2000;0c#!/bin/sh
In fact, I'm surprised that works at all.
Dave
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago Attachment: spkg-check.gz
spkg-check for Pari
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago Replying to @JohnCremona:
trac_9343-elliptic-curve.patch + http://www.warwick.ac.uk/staff/J.E.Cremona/pari-2.4.3.svn.p4.spkg
This will not install for me.
One likely cause of a problem is the Dynamic Lib linker does not include the -m64 flag (it should be included if SAGE64 is "yes").
pari-2.4.3.svn.p4/.hgignore
pari-2.4.3.svn.p4/spkg-install
Finished extraction
****************************************************
Host system
uname -a:
SunOS hawk 5.11 snv_134 i86pc i386 i86pc
****************************************************
****************************************************
CC Version
gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: /export/home/drkirkby/gcc-4.4.4/configure --prefix=/usr/local/gcc-4.4.4-multilib --enable-languages=c,c++,fortran --with-gmp=/usr/local/gcc-4.4.4-multilib --with-mpfr=/usr/local/gcc-4.4.4-multilib --disable-nls --enable-checking=release --enable-werror=no --enable-multilib --with-system-zlib --enable-bootstrap --with-gnu-as --with-as=/usr/local/binutils-2.20/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 4.4.4 (GCC)
****************************************************
./spkg-install: line 1: B1: command not found
./spkg-install: line 1: 2000: command not found
./spkg-install: line 1: 0c#!/bin/sh: No such file or directory
Configuring pari-2.4.3 (DEVELOPMENT VERSION)
Checking echo to see how to suppress newlines...
...using \c
Looking for some tools first ...
...ld is /usr/bin/ld
...zcat is /usr/bin/zcat
...gzip is /usr/bin/gzip
...ranlib is /usr/bin/ranlib
...perl is /usr/bin/perl
GNU compiler version 4.4.4 (GCC)
Given the previous choices, sizeof(long) is 8 chars.
The internal word representation of a double is not needed (64bit).
==========================================================================
Building for: ix86 running solaris (x86-64/GMP kernel) 64-bit version
==========================================================================
C compiler is gcc -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -fPIC -g -m64
Executable linker is gcc -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -fPIC -g -m64
Dynamic Lib linker is gcc -shared $(CFLAGS) $(DLCFLAGS) -Wl,-G,-h,$(LIBPARI_SONAME)
Looking in C lib for some symbols...
...Found exp2.
...Found log2.
...Found strftime.
...Found getrusage.
...Found sigaction.
...Found TIOCGWINSZ.
...Found getrlimit.
...Found stat.
...Found vsnprintf.
...Found waitpid.
...Found setsid.
...Found getenv.
...Found isatty.
...Found alarm.
...Found dlopen.
Checking for optional libraries and headers...
...Found libgmp in /export/home/drkirkby/sage-4.5/local/lib
...Found gmp header in /export/home/drkirkby/sage-4.5/local/include
ld.so.1: solaris-ix86-rlv23868: fatal: libgmp.so.10: open failed: No such file or directory
./Configure[79]: .: line 38: 24072: Killed
### Your version of GMP is too old for PARI. Please upgrade
### Building without GNU MP support
Hi-Res Graphics: none
...Found libreadline in /export/home/drkirkby/sage-4.5/local/lib
...Found readline header in /export/home/drkirkby/sage-4.5/local/include/readline
...Found history header in /export/home/drkirkby/sage-4.5/local/include/readline
...Found libtermcap in /export/home/drkirkby/sage-4.5/local/lib/
...Library termcap needed by readline
###
### Readline library detected, but does not seem to work
###
### Building without GNU readline support
Installation prefix ? [/export/home/drkirkby/sage-4.5/local]
...for architecture-independent files (share-prefix) ? [/export/home/drkirkby/sage-4.5/local/share]
Installation directories for:
...executables (gp, gphelp) ? [/export/home/drkirkby/sage-4.5/local/bin]
...libraries (libpari) ? [/export/home/drkirkby/sage-4.5/local/lib]
...include files ? [/export/home/drkirkby/sage-4.5/local/include]
...manual pages ? [/export/home/drkirkby/sage-4.5/local/share/man/man1]
...other system-dependent data ? [/export/home/drkirkby/sage-4.5/local/lib/pari]
...other system-independent data ? [/export/home/drkirkby/sage-4.5/local/share/pari]
Default is dynamic executable and shared library
==========================================================================
Extracting examples/Makefile.solaris-ix86
Extracting Osolaris-ix86/Makefile
Extracting Makefile
Extracting Osolaris-ix86/paricfg.h
Extracting Osolaris-ix86/../Odos/paricfg.h
Extracting scripts and macros
...in doc
...in misc
==========================================================================
Shall we try to build pari 2.4.3 (development) now (y/n)? [n]
Ok. Type "make install" when you are ready
Bye !
Building and install PARI
Making gp in Osolaris-ix86
make[1]: Entering directory `/export/home/drkirkby/sage-4.5/spkg/build/pari-2.4.3.svn.p4/src/Osolaris-ix86'
make[1]: warning: -jN forced in submake: disabling jobserver mode.
../config/genkernel ../src/kernel/x86_64/asm0.h > parilvl0.h
if test -r ./tune.h; then d=.; else d=../src/kernel/none; fi; cat $d/tune.h ../src/kernel/none/int.h ../src/kernel/none/level1.h > parilvl1.h
cd ../src/desc && /usr/bin/perl whatnow > whatnow-solaris-ix86-23868.tmp
cat ../src/kernel/none/mp.c ../src/kernel/none/cmp.c ../src/kernel/none/gcdll.c ../src/kernel/none/ratlift.c ../src/kernel/none/invmod.c ../src/kernel/none/gcd.c ../src/kernel/none/gcdext.c ../src/kernel/none/mp_indep.c ../src/kernel/none/add.c > mp.c
bison -d ../src/language/parse.y -o ../src/language/parse.c
make[1]: bison: Command not found
make[1]: *** [../src/language/parse.h] Error 127
make[1]: *** Waiting for unfinished jobs....
mv ../src/desc/whatnow-solaris-ix86-23868.tmp ../src/gp/whatnow.h
make[1]: Leaving directory `/export/home/drkirkby/sage-4.5/spkg/build/pari-2.4.3.svn.p4/src/Osolaris-ix86'
make: *** [gp] Error 2
Error building GP
real 0m1.203s
user 0m0.551s
sys 0m0.640s
sage: An error occurred while installing pari-2.4.3.svn.p4Is this something wrong with pari's Configure script -- in which case should be reported upstream? Or something which could be fixed by a change in the spkg-install script?
JohnCremona
commented
14 years ago Replying to @sagetrac-drkirkby:
I'm attaching a
spkg-checkfile. I originally created #9518 to add thespkg-check, but John said to leave it, and let the changes be made as part of this ticket. When this ticket gets closed, so can #9518
I found out how to exclude a test from being run with test-all (there's a list in src/config/get_test) and the next version of the spkg will patch that file appropriately.
Note there is an error in spkg-install on the first line, which displays as:
B1;2000;0c#!/bin/sh
Fixed. Probably a finger-blunder by me.
In fact, I'm surprised that works at all.
Dave
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago Replying to @JohnCremona:
Is this something wrong with pari's Configure script -- in which case should be reported upstream? Or something which could be fixed by a change in the spkg-install script?
The type at the start of spkg-install is in the current version of pari. I'm puzzled it works at all, but it seems to.
I was mistaken on the LINKER FLAGS, as that include CFLAGS, so the -m64 will get there from that.
However, this still thinks gmp is broken. The version of Pari in Sage at the moment reports:
Checking for optional libraries and headers...
...Found libgmp in /rootpool2/local/kirkby/sage-4.5-hacked-for-64-bit-solaris/local/lib
...Found gmp header in /rootpool2/local/kirkby/sage-4.5-hacked-for-64-bit-solaris/local/include
Using GNU MP, version 4.3.1
...Found libX11 in /usr/openwin/lib
...Found X11 header files in /usr/openwin/include/X11compared to this version, where I see:
Checking for optional libraries and headers...
...Found libgmp in /export/home/drkirkby/sage-4.5/local/lib
...Found gmp header in /export/home/drkirkby/sage-4.5/local/include
ld.so.1: solaris-ix86-rlv23868: fatal: libgmp.so.10: open failed: No such file or directory
./Configure[79]: .: line 38: 24072: Killed
### Your version of GMP is too old for PARI. Please upgrade
### Building without GNU MP support
Hi-Res Graphics: none
...Found libreadline in /export/home/drkirkby/sage-4.5/local/libSo something has changed for the worst.
This version from svn wants bison too, so you will have to generate the files, since bison is not a prerequisite for Sage, and is not included in Sage.
Dave
jdemeyer
commented
14 years ago Replying to @JohnCremona:
trac_9343-elliptic-curve.patch + http://www.warwick.ac.uk/staff/J.E.Cremona/pari-2.4.3.svn.p4.spkg (which upgrades to svn 12533) do the following:
- All doctests in schemes/elliptic_curves pass except heegner.py
- All doctests in interfaces/* pass except for two issues in gp.py marked not tested" for now
All in libs/ pass except some remaining issues in gen.pyx, mostly just fuzz but including one SIGSEGV
I thought this worth posting despite there still being issues in some of the files it touches.
Nice work John! Please let me know what you're working on, since I also plan to continue working on this ticket.
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago Hi, John or someone else can perhaps convey this to the Pari developers. Would it be possible for them to add the -fPIC option on at least all Solaris systems. (Both SPARC and x86). If code goes into a shared library, it should be compiled position independent. It is unreliable if this is not done. There's some relevant information about this here.
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Code-Gen-Options.html#Code-Gen-Options http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Link-Options.html#Link-Options
I believe it would be more reliable to build with -fPIC when the code is going into a shared library - irrespective of the platform. What one should ensure though is there is not a mixture of PIC and non-PIC code, as that can be unreliable too.
I've not had a chance to look at the other issues, but as far as I can see, this update completely breaks a 64-bit build on Solaris or OpenSolaris.
I've also noticed that Pari reports that readline is not working on Solaris systems. Yet the readline is definitely working in my Sage builds on Solaris. Several parts of Sage link against readline (Pari, gap, Singular, ECL, Python ...). None of them believe that readline is broken, but Pari does.
Dave
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago Looking at the error message above:
ld.so.1: solaris-ix86-rlv23868: fatal: libgmp.so.10: open failed: No such file or directory
./Configure[79]: .: line 38: 24072: Killedand comparing it to the GMP libraries that were installed, the version numbers do not match. Pari is looking for libgmp.so.10 but I have the following GMP related files:
drkirkby@hawk:~/sage-4.5/local/lib$ ls -ld libgmp*
-rwxr-xr-x+ 1 drkirkby staff 803 Jul 16 13:10 libgmp.la
lrwxrwxrwx 1 drkirkby staff 15 Jul 16 13:10 libgmp.so -> libgmp.so.3.4.6
lrwxrwxrwx 1 drkirkby staff 15 Jul 16 13:10 libgmp.so.3 -> libgmp.so.3.4.6
-rwxr-xr-x+ 1 drkirkby staff 549536 Jul 16 13:10 libgmp.so.3.4.6
-rwxr-xr-x+ 1 drkirkby staff 919 Jul 16 13:10 libgmpxx.la
lrwxrwxrwx 1 drkirkby staff 17 Jul 16 13:10 libgmpxx.so -> libgmpxx.so.3.1.6
lrwxrwxrwx 1 drkirkby staff 17 Jul 16 13:10 libgmpxx.so.3 -> libgmpxx.so.3.1.6
-rwxr-xr-x+ 1 drkirkby staff 26712 Jul 16 13:10 libgmpxx.so.3.1.6i.e. there is nothing like a version 10. The installed libraries have a 3.x in them, but Pari is looking for a .10.
I've installed bison on the system, so the error message about a missing bison is not appearing any more, but that has not resolve either
Dave
JohnCremona
commented
14 years ago Nice work John! Please let me know what you're working on, since I also plan to continue working on this ticket.
Thanks. I finished fixing the interfaces/gp and very nearly finished libs/pari/ . The serious issues are gone now. I fear that the flood of newly merged tickets for 4.5.2 will require some rebasing, so as soon as I have tidied up I will post the revised patches and a new spkg (p5). I have not touched anything in number_fields since you did, but it still might be a good idea to wait until I have posted what I have done.
JohnCremona
commented
14 years ago Replying to @sagetrac-drkirkby:
Hi, John or someone else can perhaps convey this to the Pari developers. Would it be possible for them to add the -fPIC option on at least all Solaris systems. (Both SPARC and x86). If code goes into a shared library, it should be compiled position independent. It is unreliable if this is not done. There's some relevant information about this here.
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Code-Gen-Options.html#Code-Gen-Options http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Link-Options.html#Link-Options
I believe it would be more reliable to build with -fPIC when the code is going into a shared library - irrespective of the platform. What one should ensure though is there is not a mixture of PIC and non-PIC code, as that can be unreliable too.
I've not had a chance to look at the other issues, but as far as I can see, this update completely breaks a 64-bit build on Solaris or OpenSolaris.
I've also noticed that Pari reports that readline is not working on Solaris systems. Yet the readline is definitely working in my Sage builds on Solaris. Several parts of Sage link against readline (Pari, gap, Singular, ECL, Python ...). None of them believe that readline is broken, but Pari does.
Dave
I was planning to do this (report upstream). On the positive side, they just put in a patch which obviates the need for 2/3 of our patch to the header files paripriv/paridecl.h.
I think we will have a better chance of a positive reaction if we could report to pari a failure to build of pari as such and not pari-in-Sage, since they would reasonably reposond that as we patch some files they cannot be responsible. For this, just copy the src directory of the most recent spkg (or wait until I put up p5 later today) and try it directly, after ./Configure
kiwifb
commented
14 years ago Am I the only one seeing problems with lcalc and genus2reduction?
JohnCremona
commented
14 years ago Replying to @kiwifb:
Am I the only one seeing problems with lcalc and genus2reduction?
I don't think you are. I have been sorting out other things! I have just finished with the (rather important) sage/libs/pari and sage/intergaces/gp, with everything working except (bizarrely) the hyperbolic tangent function.
kiwifb
commented
14 years ago Replying to @JohnCremona:
Replying to @kiwifb:
Am I the only one seeing problems with lcalc and genus2reduction?
I don't think you are. I have been sorting out other things! I have just finished with the (rather important) sage/libs/pari and sage/intergaces/gp, with everything working except (bizarrely) the hyperbolic tangent function.
OK. I can attach some fixes for lcalc later, but I am stuck for genus2reduction.
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago Replying to @JohnCremona:
I think we will have a better chance of a positive reaction if we could report to pari a failure to build of pari as such and not pari-in-Sage, since they would reasonably reposond that as we patch some files they cannot be responsible. For this, just copy the src directory of the most recent spkg (or wait until I put up p5 later today) and try it directly, after ./Configure
and make whatever.
John,
I'm going to attach to the ticket a failure observed with the Pari source code directly - outside of Sage. No compiler flags were set.
The hack of mine in Sage (adding -fPIC) resolves this, but it would be better if it could be fixed upstream. The file was actually 5.1 MB in size, as there are over 95,000 error messages. I've reduce the filed to 23 KB, but removing tons of very similar looking messages. See the file:
Pari-trunk-failure-on-OpenSolaris_x64.log.txt
There are similar issues on Solaris 10 SPARC. I can attach a log if needed, or someone can just try to build on 't2' outside of Pari. You will see very similar.
I believe this should be applied on all platforms, as it will be more reliable. The code should be position independent if you are building shared libraries.
Dave
Dave
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago Failure of Pari source code to build outside of Sage on an OpenSolaris machine
bac7d3ea-3f1b-4826-8464-f0b53d5e12d2
commented
14 years ago Attachment: Pari-trunk-failure-on-OpenSolaris_x64.log.txt
Replying to @sagetrac-drkirkby:
There are similar issues on Solaris 10 SPARC. I can attach a log if needed, or someone can just try to build on 't2' outside of Pari. You will see very similar.
I believe this should be applied on all platforms, as it will be more reliable. The code should be position independent if you are building shared libraries.
Dave
I mean someone could try this on 't2.math.washington.edu' without using Sage. I'm sure William would set up an account for a Pari developer. They only need the Pari source - no Sage code to reproduce this error.
Dave
jdemeyer
commented
14 years ago I have sent a bug report to the PARI people about Solaris: http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1078
JohnCremona
commented
14 years ago Replying to @kiwifb:
Replying to @JohnCremona:
Replying to @kiwifb:
Am I the only one seeing problems with lcalc and genus2reduction?
I don't think you are. I have been sorting out other things! I have just finished with the (rather important) sage/libs/pari and sage/intergaces/gp, with everything working except (bizarrely) the hyperbolic tangent function.
OK. I can attach some fixes for lcalc later, but I am stuck for genus2reduction.
In my current setup, sage/interfaces/genus2reduction passes, as does sage/lfunctions/lcalc.
I did not need to make any changes to lcalc!
kiwifb
commented
14 years ago I am not talking about any tests. I didn't check that. I was talking about building them. And from what I am just digging, the failure for genus2reduction is not just my set up.
See #7736 (a bug this will fix), #8453 (last pari upgrade).
See http://wiki.sagemath.org/NewPARI for more information and links.
CC: @robertwb @loefflerd @JohnCremona @jdemeyer
Component: packages: standard
Author: Robert Bradshaw, John Cremona, Jeroen Demeyer, William Stein, David Kirkby
Reviewer: Robert Bradshaw, John Cremona, Jeroen Demeyer, William Stein, David Kirkby, François Bissey, Leif Leonhardy
Merged: sage-4.6.alpha0
Issue created by migration from https://trac.sagemath.org/ticket/9343