Opened 9 years ago

Last modified 9 years ago

#9533 closed enhancement

Update GSL to the latest upstream release (1.14) & permit parallel building. — at Version 11

Reported by: drkirkby Owned by: tbd
Priority: major Milestone: sage-4.5.3
Component: packages: standard Keywords:
Cc: leif, mpatel Merged in:
Authors: David Kirkby Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by drkirkby)

The version of the GNU Scientific Library (GSL) in Sage is 1.10, which is almost 3 years old. The latest, 1.14 was released about 4 months ago.

There is also a large number of bugs in the spkg-check and spkg-install files

  • spkg-check did not exit with a non-zero error code if the make check failed. It did however report the error, but it is highly likely to be missed in a large log file. This issue was reported at #9531, so that ticket can be closed when this one is closed.
  • spkg-install did not exit if configure failed to configure properly. Again the error was reported.
  • spkg-install did not exit if make failed to build GSL correctly. Again the error was reported.
  • spkg-install did not exit if make install failed to install GSL properly. Again the error was reported.
  • The self-tests were failing on some platforms, due to the fact /bin/rm: cannot remove `libtoolT. This was also true of the latest version, but exporting RM to "rm -f" solved that, as suggested at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523750

Change History (15)

comment:1 follow-up: Changed 9 years ago by mpatel

A possibility for another ticket: Checking whether we can replace make with $MAKE in GSL's spkg-install.

comment:2 in reply to: ↑ 1 Changed 9 years ago by drkirkby

Replying to mpatel:

A possibility for another ticket: Checking whether we can replace make with $MAKE in GSL's spkg-install.

I'm pretty sure we can, since I have built this multiple times on my Sun Blade 2000 SPARC with 2 threads and on my Sun Ultra 27 with 12 threads. This is outside the Sage environment, so my settings for MAKE would have been used. There were no problems building on either in parallel, so I don't think it will be a problem building with $MAKE.

I'll test that before uploading a patch and providing a link.

Dave

comment:3 Changed 9 years ago by drkirkby

  • Summary changed from Update GSL to the latest upstream release to Update GSL to the latest upstream release (1.14) & permit parallel building.

I'm convinced this is ok built in parallel. I tested it several times in parallel (outside of Sage) before you even mentioned it. But after you said this, I used $MAKE in spkg-install and systematically checked it on different systems

  • 19 parallel builds on a Sun Ultra 27, with OpenSolaris using between 2 and 1000 threads.
  • 5 parallel builds on bsd.math, with OS 10.6, using 4 threads.
  • 5 parallel builds on sage.math, with Ubunta, using 8 threads.
  • 3 parallel builds on a Sun Blade 2000, with Solaris 10, using between 2 and 4 threads. (Code compiled 64-bit)
  • 3 parallel builds on a Sun Blade 2000, with Solaris 10, using between 2 and 4 threads. (Code compiled 32-bit)

In all cases, all the self-tests for GSL passed.

I've run the doctests on sage.math. I was quite expecting to get a few failures due to different results from different algorithms that might be used in the GSL library, but to my surprise:

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 1095.8 seconds
kirkby@sage:/scratch/kirkby/sage-4.5$ 

Here's a link to the package.

http://boxen.math.washington.edu/home/kirkby/patches/gsl-1.14.spkg

I'm going to upload 3 patches. The first was all the updates. The second uses {{{$MAKE}} and the final one just prints an informative message when the tests pass. Is there a sensible way of reversing these patches once they are commited, so I don't need 3 of them? Anyway, the patches are for review only. They don't need to be applied to the package.

The first patch is quite large, as it removes a big patch.

Dave Dave

Changed 9 years ago by drkirkby

Main patch, which makes many changes to clean up the spkg-check and spkg-install.

Changed 9 years ago by drkirkby

Changes 'make' to '$MAKE' to allow faster parallel builds. This has been extensively tested

Changed 9 years ago by drkirkby

Add a message to indicate the tests have passed.

comment:4 Changed 9 years ago by drkirkby

  • Authors set to David Kirkby
  • Status changed from new to needs_review

comment:5 Changed 9 years ago by drkirkby

  • Type changed from defect to enhancement

comment:6 Changed 9 years ago by drkirkby

On bsd.math

$ make ptestlong

<SNIP> 

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 2503.7 seconds
[kirkby@bsd sage-4.5.rc1]$ 

comment:7 follow-ups: Changed 9 years ago by leif

At first glance (I only looked at the patches) ok, except

  • Append to CFLAGS et al. rather than set/overwrite them
  • Typo: 1x s/builing/building/ (2nd patch SPKG.txt)
  • Perhaps add to SPKG.txt that spkg-check also now uses $MAKE
  • Move the "successful check" message out of the else part, right to the bottom ;-)

I don't know why you want to create a single patch, but you can simply take an old vanilla GSL spkg and apply your patches in order with hg import --no-commit ... (or use patch), and after that, just do a commit.

I'll take a closer look at the package tomorrow, I think.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 9 years ago by leif

Replying to leif:

you can simply take an old vanilla GSL spkg and apply your patches in order with hg import --no-commit ... (or use patch), and after that, just do a commit.

Oh, I just noticed Mercurial doesn't like successive imports without commit, simply use patch < ... for the second and third.

comment:9 in reply to: ↑ 8 Changed 9 years ago by leif

Replying to leif:

Oh, I just noticed Mercurial doesn't like successive imports without commit, simply use patch < ... for the second and third.

hg import -f --no-commit ... (three times) does the trick as well... :)

comment:10 in reply to: ↑ 7 Changed 9 years ago by drkirkby

Replying to leif:

At first glance (I only looked at the patches) ok, except

  • Append to CFLAGS et al. rather than set/overwrite them

OK.

  • Typo: 1x s/builing/building/ (2nd patch SPKG.txt)

Cheers

  • Perhaps add to SPKG.txt that spkg-check also now uses $MAKE

Yes.

  • Move the "successful check" message out of the else part, right to the bottom ;-)

Yes, good idea. It saves a few bytes.

I don't know why you want to create a single patch

I think its more difficult to read patches when they are very small. I'd personally rather see one patch that fixes all the problems, rather than loads of patches fixing parts of it. But I'll just add another patch here.

Dave

comment:11 Changed 9 years ago by drkirkby

  • Description modified (diff)

Changed 9 years ago by drkirkby

Patch taking into account comments by reviewer, and a bit of a tidyup.

Note: See TracTickets for help on using tickets.