Ensure that libraries link to the shared version of NTL by default

[kcrisman]

In #11547, we added copying of several needed dlls on Cygwin. However, in the meantime NTL had a fairly major update (#5731).

From version 5.5, NTL provides a new build system using libtool (although libtool itself is not provided!) to generate shared libraries. On Cygwin, libtool properly install the shared library as cygntl-?.dll in the bin directory and the import file as libntl.dll.a in the lib directory, together with a libtool file libntl.la and a static version of the library as libntl.a.

In particular, this ensures that the shared version is linked with by default because ld/gcc/g++ find the .dll.a file in the lib directory (which points to the dll file in the bin directory) before the .a file.

Moreover, only moving the previously built libntl.dll to libntl.dll.a was not a solution. Indeed, the built file hardcoded its own build-time name into itself (as a DT_SONAME on linux), so that libraries linked to it (before or after renaming, does not matter) would in fact search for a file with the build time name... and fail.

spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/ntl-5.5.2.p0.spkg

This spkg vastly simplifies the old spkg-install, uses the (slightly patched) upstream build system and includes its own version of libtool (or rather the tools needed to generate it on the fly).

CC: @mwhansen @dimpase @jpflori @jdemeyer

Component: porting: Cygwin

Keywords: cygwin ntl libtool spkg

Author: Jean-Pierre Flori

Reviewer: Karl-Dieter Crisman

Merged: sage-5.6.beta3

Issue created by migration from https://trac.sagemath.org/ticket/11635

[kcrisman]

Description changed:

--- 
+++ 
@@ -1,6 +1,8 @@
 In #11547, we added copying of several needed dlls on Cygwin.  However, in the meantime NTL had a fairly major update (#5731).

 Based on this, this ticket splits off the NTL change from #11547 so that that ticket can get merged.  
+
+Spkg at [http://sage.math.washington.edu/home/kcrisman/ntl-5.5.2.p0.spkg](http://sage.math.washington.edu/home/kcrisman/ntl-5.5.2.p0.spkg).

 Here is the previous diff - presumably we would do the same thing if we can confirm it is still necessary, which is almost certainly the case.

[kcrisman]

comment:1

New spkg at http://sage.math.washington.edu/home/kcrisman/ntl-5.5.2.p0.spkg. No guarantees on whether this works, or even is necessary (!) but I strongly suspect both. You'll know it works if you do everything at #6743, including this, and then Sage has a segfault on startup.

In case there is any doubt that this is Cygwin-only:

    elif [ $UNAME = "CYGWIN" ]; then
        # Cygwin
        if [ "$CYGPKG" = "yes" ]; then
            if [ -f /lib/libgmp.dll.a ]; then
                ln -s /lib/libgmp.dll.a libgmp.a
            else
                # Added by William Stein on 2006-02-06 so that 
                # can build even if gmp is not built locally
                # i.e., even if using a system-wide gmp.
                # (though it has to be in /usr/lib, which is
                # where it is for cygwin).
                ln  -s /usr/lib/*gmp* .
                ln  -s libgmp.dll.a libgmp.a
            fi 
        else
        ln -s "$SAGE_LOCAL/lib/libgmp.a" .
        fi
    $MAKE libntl.dll
        if [ ! -f libntl.dll ]; then
            echo "Error creating ntl shared library."
            exit 1
        fi
    cp libntl.dll "$SAGE_LOCAL/lib/libntl.dll.a"
    cp libntl.dll "$SAGE_LOCAL/lib/libntl.dll"
    cp libntl.dll "$SAGE_LOCAL/bin/libntl.dll.a"
    cp libntl.dll "$SAGE_LOCAL/bin/libntl.dll"
        if [ ! -f "$SAGE_LOCAL/bin/libntl.dll.a" ]; then
            exit 1   # CRUCIAL that we have the dynamic link library
        fi

[kcrisman]

Author: Karl-Dieter Crisman

[kcrisman]

comment:3

Interestingly, the most recent alpha I tested all the Cygwin stuff on a few weeks ago already had NTL 5.5.2!

$ ls spkg/installed
<snip>
ntl-5.5.2
<snip>

and it seemed to work fine (in the sense that it got to the Pari segfault when initializing).

That doesn't mean that later in the process things wouldn't happen, but at least for now this ticket can be lower priority, if it's needed at all, since we have to figure out how to get past that error first.

[kcrisman]

comment:5

This appears to be the same issue as #12104, which should probably be closed as a duplicate then.

[kcrisman]

comment:6

Since the 4.8.alpha3 spkg still is 5.5.2 with no patches, this spkg should still be valid to fix this.

[kcrisman]

comment:7

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

[dimpase]

comment:8

Replying to @kcrisman:

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

Why does one need copies in local/bin ? And why does one need to copy rather than to create a symbolic link?

[kcrisman]

comment:9

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

Why does one need copies in local/bin ? And why does one need to copy rather than to create a symbolic link?

No idea! I just copied models from other spkgs. Feel free to only copy and/or make links where actually appropriate. I have never claimed to be anything close to an expert; I've only focused on getting it to work by following other spkgs I've seen.

I would love to have this "correct" so that we never have to worry about it again.

[kcrisman]

comment:10

Replying to @kcrisman:

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

Why does one need copies in local/bin ? And why does one need to copy rather than to create a symbolic link?

No idea! I just copied models from other spkgs. Feel free to only copy and/or make links where actually appropriate. I have never claimed to be anything close to an expert; I've only focused on getting it to work by following other spkgs I've seen.

I would love to have this "correct" so that we never have to worry about it again.

This might even be part of the problem at #9167.

[kcrisman]

comment:11

Replying to @kcrisman:

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

Why does one need copies in local/bin ? And why does one need to copy rather than to create a symbolic link?

Just for posterity (addressing the comments at #12104, perhaps?), here is the rationale for naming it dll.a, from #9050.

This is so that Cygwin will find the shared library before it finds the static library; otherwise, there are lots of segfaults in Sage under Cygwin

[dimpase]

comment:12

Replying to @kcrisman:

Replying to @kcrisman:

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

Why does one need copies in local/bin ? And why does one need to copy rather than to create a symbolic link?

Just for posterity (addressing the comments at #12104, perhaps?), here is the rationale for naming it dll.a, from #9050.

This is so that Cygwin will find the shared library before it finds the static library; otherwise, there are lots of segfaults in Sage under Cygwin

that means that only in the cases when both static and dynamic libraries are built, this is needed. IMHO there are not so many such cases among Sage spkg's.

[dimpase]

comment:13

Replying to @kcrisman:

Replying to @kcrisman:

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

Why does one need copies in local/bin ? And why does one need to copy rather than to create a symbolic link?

Just for posterity (addressing the comments at #12104, perhaps?), here is the rationale for naming it dll.a, from #9050.

This is so that Cygwin will find the shared library before it finds the static library; otherwise, there are lots of segfaults in Sage under Cygwin

IMHO, this is, at best, a bad hack. In principle, .dll.a files are import libraries for .dll libaries, used by the linker to like against *.dll (i.e. dynamic libraries).

See Buiding/using DLLs

[kcrisman]

comment:14

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

Why does one need copies in local/bin ? And why does one need to copy rather than to create a symbolic link?

Just for posterity (addressing the comments at #12104, perhaps?), here is the rationale for naming it dll.a, from #9050.

This is so that Cygwin will find the shared library before it finds the static library; otherwise, there are lots of segfaults in Sage under Cygwin

IMHO, this is, at best, a bad hack. In principle, .dll.a files are import libraries for .dll libaries, used by the linker to like against *.dll (i.e. dynamic libraries).

Well, as I said in comment:9, I would more than happy to have someone who actually knows what they are talking about to fix this and post a different spkg :) especially if it ended up fixing #9167. Go for it!

[dimpase]

comment:15

Replying to @kcrisman:

Replying to @kcrisman:

Oh, and no longer 'needs info', because #12104 shows that it's needed to start Sage.

Why does one need copies in local/bin ? And why does one need to copy rather than to create a symbolic link?

Just for posterity (addressing the comments at #12104, perhaps?), here is the rationale for naming it dll.a, from #9050.

This is so that Cygwin will find the shared library before it finds the static library; otherwise, there are lots of segfaults in Sage under Cygwin

It's probably OK to have "real" (i.e. dynamic libs, not misnamed dll.a or other files) .dlls in local/bin/, and bad to have them in local/lib/. At least that's what a Cygwin-aware libtool will be doing.

[kcrisman]

comment:16

It's probably OK to have "real" (i.e. dynamic libs, not misnamed dll.a or other files) .dlls in local/bin/, and bad to have them in local/lib/. At least that's what a Cygwin-aware libtool will be doing.

Can you be more specific (if only so I can make a good spkg)? Please check which of the following should be copied, which should be linked (with ln -s, or with other options?), and which are just horrible.

• lib/libntl.dll
• lib/libntl.dll.a
• bin/libntl.dll
• bin/libntl.dll.a Recall that currently we also have
• lib/libntl.a

[kcrisman]

comment:17

Here's something else potentially relevant.

User 1@GC02635 /home/SageUser/sage-4.7.2
$ ./sage -t -verbose devel/sage/sage/calculus/functional.py
init.sage does not exist ... creating
sage -t -verbose "devel/sage/sage/calculus/functional.py"
Setting permissions of DOT_SAGE directory so only you can read and write it.
<snip LOTS of pretty much identical things>
1564601 [main] python 3544 fork: child 3776 - died waiting for dll loading, errno 11
1639139 [main] python 160 C:\cygwin\home\SageUser\sage-4.7.2\local\bin\python.exe: *** fatal error - unable to remap C:\cygwin\home\SageUser\sage-4.7.2\local\lib\libntl.dll to same address as parent: 0x19A40000 != 0x626C0000
Stack trace:
Frame     Function  Args
002093B8  6102796B  (002093B8, 00000000, 00000000, 00000000)
002096A8  6102796B  (6117EC60, 00008000, 00000000, 61180977)
0020A6D8  61004F1B  (611A7FAC, 6124A1B4, 19A40000, 626C0000)
End of stack trace
1642317 [main] python 3544 fork: child 160 - died waiting for dll loading, errno 11
Traceback (most recent call last):
  File "../.sage/tmp/functional_3772.py", line 6, in <module>
    from sage.all_cmdline import *;
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/all_cmdline.py", line 14, in <module>
    from sage.all import *
<snip>
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/rings/polynomial/multi_polynomial_ideal.py", line 235, in <module>
    from sage.interfaces.all import (singular as singular_default,
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/interfaces/all.py", line 8, in <module>
    from gap import gap, gap_reset_workspace, gap_console, gap_version, is_GapElement, Gap
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/interfaces/gap.py", line 1188, in <module>
    gap_reset_workspace(verbose=False)
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/interfaces/gap.py", line 1179, in gap_reset_workspace
    g.save_workspace()
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/interfaces/gap.py", line 983, in save_workspace
    self.eval('SaveWorkspace("%s");'%WORKSPACE, allow_use_file=False)
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/interfaces/gap.py", line 374, in eval
    result = Expect.eval(self, input_line, **kwds)
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/interfaces/expect.py", line 1039, in eval
    for L in code.split('\n') if L != ''])
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/interfaces/gap.py", line 476, in _eval_line
    self._start()
  File "/home/SageUser/sage-4.7.2/local/lib/python/site-packages/sage/interfaces/gap.py", line 913, in _start
    raise RuntimeError, msg
RuntimeError: Unable to start gap because the command 'gap -r -b -p -T -o 3900m /home/SageUser/sage-4.7.2/data//extcode/gap/sage.g' failed.

         [11.4 s]

----------------------------------------------------------------------
The following tests failed:

        sage -t -verbose "devel/sage/sage/calculus/functional.py"
Total time for all tests: 11.7 seconds

[dimpase]

comment:18

Replying to @kcrisman:

Here's something else potentially relevant.

the usual Cygwin fork() crap, no?

[kcrisman]

comment:19

Here's something else potentially relevant.

the usual Cygwin fork() crap, no?

I didn't think so, but apparently it was. Sorry for that last bit o' noise.

Any comments on which of the files above are "correct"?

[dimpase]

comment:20

Replying to @kcrisman:

Here's something else potentially relevant.

the usual Cygwin fork() crap, no?

I didn't think so, but apparently it was. Sorry for that last bit o' noise.

Any comments on which of the files above are "correct"?

It would be good to find this out by looking at the working Python extensions in Sage --- what they do, how the files are built and named, etc. I think that also the information in Autobook is very relevant.

But I am afraid that we will also need to solve the fork() issue, which seems to mean eliminating the use of fork() in Python and Cython parts, at least. This is doable, but quite a lot of work... (unless an überhacker fixes fork() directly in Cygwin ––– probably needs a lot of very delicate reverse engineering of Windows kernel; the fact that is has not yet been done speaks volumes :-( )...

[kcrisman]

comment:21

This apparently is still needed, and someone who knows what they are talking about rediscovered it :)

[jpflori]

comment:22

I think the better solution would be to use the libtool build system the latest version of NTL propose.

Anyway, I found it quite strange that csage.dll wants a file called libntl.dll although only a file called libntl.dll.a was available at link time. Maybe there is a kind of DT_SONAME hidden in the NTL shared library.

[jpflori]

comment:23

There is indeed a linbntl.dll string within the shared library, so that may be it. Try strings libntl.dll | grep libntl.dll

Anyway, using libtool should solves our problem. At least I have previously built NTL properly with that on Cygwin and Linux. Let's hope it does not break on other systems.

[jpflori]

comment:24

Proof of concept spkg available at http://perso.telecom-paristech.fr/~flori/sage/ntl-5.5.2.p0.spkg

The regenerated patches need to be split. I've removed quite all biuld hacks to only use the NTL build system. This seems ok on Linux, I'll check Cygwin now.

[jpflori]

comment:25

The updated spkg depends on libtool (ok, this was somehow to be expected), which is not needed by any other part of Sage. Too bad.

[jpflori]

comment:27

And the spkg I posted needs to pass LDFLAGS=-no-undefined to NTL to be able to build a shared library on cygwin.

[jpflori]

comment:28

The spkg at http://perso.telecom-paristech.fr/~flori/sage/ntl-5.5.2.p0.spkg is cleaner, functional, but still depends on libtool being system-wide installed.

[dimpase]

comment:29

Replying to @jpflori:

The spkg at http://perso.telecom-paristech.fr/~flori/sage/ntl-5.5.2.p0.spkg is cleaner, functional, but still depends on libtool being system-wide installed.

I am trying this spkg now. My build (with an older NTL) has finished, but I see exactly the same problem as reported on #12104.

[jpflori]

comment:30

It could be that some of your already build dlls are still linked with libntl.dll (which should still be inexistant if you did not copy it by hand earlier). You can check that by cygchecking some of them, sage/rings/... should be good culprits or sage/libs/ntl.... So you should rebuild all these broken dlls. Unfortunately I'm not sure yet how to easily automagically make them rebuild (as sage -b will not). I'm currently seeing if touching sage/libs/ntl/decl.pxi is enough to trigger that rebuild. Some spkg depending on NTL may be broken as well...

The easiest solution would be to rebuild from scratch...

[dimpase]

comment:31

Replying to @dimpase:

Replying to @jpflori:

The spkg at http://perso.telecom-paristech.fr/~flori/sage/ntl-5.5.2.p0.spkg is cleaner, functional, but still depends on libtool being system-wide installed.

I am trying this spkg now. My build (with an older NTL) has finished, but I see exactly the same problem as reported on #12104.

The spkg does not build. It ends up with rather weird message:

g++: /usr/lib/gcc/i686-pc-cygwin/4.3.4/crtbegin.o: No such file or directory
g++: /usr/lib/gcc/i686-pc-cygwin/4.3.4/crtend.o: No such file or directory
makefile:376: recipe for target `ntl.a' failed
make[1]: *** [ntl.a] Error 1
make[1]: Leaving directory `/usr/local/src/sage/sage-5.2/spkg/build/ntl-5.5.2.p0/src/src'
makefile:334: recipe for target `all' failed
make: *** [all] Error 2
Unable to tune and build NTL.

And indeed, my gcc is 4.5.3, and I have stuff in /usr/lib/gcc/i686-pc-cygwin/4.5.3/, but no /usr/lib/gcc/i686-pc-cygwin/4.3.4/

Please see the log here

[jpflori]

comment:32

This is because the postinstall script from the Cygwin gcc4-core package is broken. I've posted additional details on the CygwinPort page. You'll have to tweak the /usr/bin/libtool file yourself for now, replacing 4.3.4 by 4.5.3 (or reinstalling version 4.3.4 of gcc4 package).

[jpflori]

comment:33

By the way, touching decl.pxi in sage/libs/ntl and then running "sage -b" seems to have fixed my install. At least Sage starts now without import errors.

[kcrisman]

comment:34

wrt to the libtool business - this doesn't become a Sage dependency though, right? Or could one just make it a Cygwin one (that's ok)? Sorry for being dense here.

[dimpase]

comment:35

Replying to @jpflori:

By the way, touching decl.pxi in sage/libs/ntl and then running "sage -b" seems to have fixed my install. At least Sage starts now without import errors.

not for me - I still needed to copy SAGELOCAL/bin/libntl.dll.a to SAGELOCAL/bin/libntl.dll to get past import errors.

Then, the usual fork() problems on startup, and rebaseall does not help. I am afraid we're back to the root of the problem. I'll try to rebuild from scratch one more time, but this doesn't look good.

[jpflori]

comment:36

Replying to @dimpase:

Replying to @jpflori:

By the way, touching decl.pxi in sage/libs/ntl and then running "sage -b" seems to have fixed my install. At least Sage starts now without import errors.

not for me - I still needed to copy SAGELOCAL/bin/libntl.dll.a to SAGELOCAL/bin/libntl.dll to get past import errors.

Then, the usual fork() problems on startup, and rebaseall does not help. I am afraid we're back to the root of the problem. I'll try to rebuild from scratch one more time, but this doesn't look good.

I also rebuild some spkg, at least flint, don't remember exactly which ones, could you check every dll? Writing such a script would be less time consuming than rebuilding Sage from scratch (and I did not have to rebase by the way). It would be really strange that some files still link to libntl.dll with a fresh instlal, as there is definitely no reference to such a file name with the new spkg, nor in other pieces of Sage.

Once again, I think that the problem before was just that there was some kind of DT_SONAME (which usually point to a "real" filename to use for a library at runtime) in the library buid by NTL. As the library was originally build as libntl.dll, this DT_SONAME was set to libntl.dll, so even though the library was rename to libntl.dll.a after installing and so was found before the static archive when we link to NTL, at runtime the pieces of Sage linked to it would look to libntl.dll.

With the new spkg libntl.dll never sees the light of day, so there is no reason something else thinks it has ever existed, or will.

And yes unfortunately, libtool is used on every platform, not only on Cygwin, the good point is that we use the upstream NTL build system rather than the one that was made only for Sage by Sage devs before it was more or less integrated with the help of the same people to NTL itself (although with a dependency on libtool). Nevertheless, libtool should only be 4 text files, so I'm looking for a way to integrate it to the spkg right now. Another solution is to continue with the Sage patched build system and add a proper linking line for Cygwin.

[jpflori]

comment:37

Could you run the following in your cygwin shell in a "sage -sh":

for d in `find . -name *.dll`; do echo $d; cygcheck $d|grep "not find"; done

and try to rebuild the libs whining about libntl.dll.

By the way, on my system, some dlls from R complain about libR.dll...

[jpflori]

comment:38

To actually 'find' the dlls of the Sage library, I had to 'cd' to local/lib/python/site-packages/sage/

[jpflori]

comment:39

And that showed me that I need to rebuild eclib which still looks fro libntl.dll :)

And that libs/lcalc/lcalc_Lfunction.dll looks for a libLfunction.so file.

[jpflori]

comment:40

Spkg updated to include libtool.

Ok on Linux, testing now on Cygwin.

[jpflori]

comment:41

In fact the included libtool does not work well on Cygwin. For some reason it decides to use gcc rather than g++ for the final linking and spits out a HUGE amount of undefined references to std::* stuffs.

[jpflori]

comment:42

Ok that's just a matter of adding -lstdc++ to the LDLIBS.

[dimpase]

comment:43

Replying to @jpflori:

Ok that's just a matter of adding -lstdc++ to the LDLIBS.

I'm doing the full rebuild. I even had to remove /etc/rebase* database and only then rebaseall, otherwise fork() errors kept popping up.

Please provide an updated ntl spkg.

[dimpase]

comment:44

Replying to @dimpase:

Replying to @jpflori:

By the way, touching decl.pxi in sage/libs/ntl and then running "sage -b" seems to have fixed my install. At least Sage starts now without import errors.

not for me - I still needed to copy SAGELOCAL/bin/libntl.dll.a to SAGELOCAL/bin/libntl.dll to get past import errors.

Then, the usual fork() problems on startup, and rebaseall does not help. I am afraid we're back to the root of the problem. I'll try to rebuild from scratch one more time, but this doesn't look good.

This might be due to the fact that I tried to follow your instruction to rebase everything in SAGEROOT rather than in SAGELOCAL, i.e. in SAGEROOT/local/, as I did before. In particular, there were dlls in devel/sage/build, which are not used, and this perhaps unnecessarily clogged up the address space.

[83660e46-0051-498b-a8c1-f7a7bd232b5a]

comment:45

Replying to @jpflori:

Replying to @dimpase:

Replying to @jpflori:

By the way, touching decl.pxi in sage/libs/ntl and then running "sage -b" seems to have fixed my install.

I also rebuild some spkg, at least flint, don't remember exactly which ones, could you check every dll? Writing such a script would be less time consuming than rebuilding Sage from scratch (and I did not have to rebase by the way).

To rebuild all spkgs that depend on NTL you can do

$ touch spkg/installed/ntl-*  # Of course not needed if you just (re)built it
$ env SAGE_UPGRADING=yes make build

You may still have to run ./sage -ba-force afterwards; not sure whether module_list.py really covers all dependencies (on NTL in this case, but probably indirect dependencies as well).

Should still be faster than rebuilding all from scratch... ;-)

[jpflori]

comment:46

The one I just uploaded should be fine. It builds ok on Linux, and I am testing it right now on Cygwin.

[jpflori]

Changed keywords from none to cygwin ntl libtool spkg

[jpflori]

Description changed:

--- 
+++ 
@@ -1,49 +1,13 @@
 In #11547, we added copying of several needed dlls on Cygwin.  However, in the meantime NTL had a fairly major update (#5731).

-Based on this, this ticket splits off the NTL change from #11547 so that that ticket can get merged.  
+From version 5.5, NTL provides a new build system using libtool (although libtool itself is not provided!) to generate shared libraries.
+On Cygwin, libtool properly install the shared library as cygntl-?.dll in the bin directory and the import file as libntl.dll.a in the lib directory, together with a libtool file libntl.la and a static version of the library as libntl.a.

-Spkg at [http://sage.math.washington.edu/home/kcrisman/ntl-5.5.2.p0.spkg](http://sage.math.washington.edu/home/kcrisman/ntl-5.5.2.p0.spkg).
+In particular, this ensures that the shared version is linked with by default because ld/gcc/g++ find the .dll.a file in the lib directory (which points to the dll file in the bin directory) before the .a file.

-Here is the previous diff - presumably we would do the same thing if we can confirm it is still necessary, which is almost certainly the case.
+Moreover, only moving the previously built libntl.dll to libntl.dll.a was not a solution.
+Indeed, the built file hardcoded its own build-time name into itself (as a DT_SONAME on linux), so that libraries linked to it (before or after renaming, does not matter) would in fact search for a file with the build time name... and fail.

-```
-diff -r 6cf0ce59b84a SPKG.txt
---- a/SPKG.txt Tue May 25 15:56:29 2010 -0700
-+++ b/SPKG.txt Tue Jun 28 22:44:18 2011 -0400
-@@ -2,7 +2,10 @@
- 
- == Description ==
- 
--NTL is a high-performance, portable C++ library providing data structures and algorithms for manipulating signed, arbitrary length integers, and for vectors, matrices, and polynomials over the integers and over finite fields. 
-+NTL is a high-performance, portable C++ library providing data 
-+structures and algorithms for manipulating signed, arbitrary 
-+length integers, and for vectors, matrices, and polynomials over 
-+the integers and over finite fields. 
- 
- Website: http://www.shoup.net/ntl/
- 
-@@ -27,6 +30,10 @@
- 
- == Changelog ==
- 
-+=== ntl-5.4.2.p13 (Karl-Dieter Crisman, June 28th 2011) ===
-+ * Keep libntl.dll but also require libntl.dll.a on Cygwin.
-+   This seems to be necessary for Sage to start - see #11547.
-+
- === ntl-5.4.2.p12 (Mike Hansen, May 25th 2010) ===
-  * Rename libntl.dll to libntl.dll.a on Cygwin.  This is #9050.
- 
-diff -r 6cf0ce59b84a spkg-install
---- a/spkg-install Tue May 25 15:56:29 2010 -0700
-+++ b/spkg-install Tue Jun 28 22:44:18 2011 -0400
-@@ -120,7 +120,9 @@
-             exit 1
-         fi
-   cp libntl.dll "$SAGE_LOCAL/lib/libntl.dll.a"
-+  cp libntl.dll "$SAGE_LOCAL/lib/libntl.dll"
-   cp libntl.dll "$SAGE_LOCAL/bin/libntl.dll.a"
-+  cp libntl.dll "$SAGE_LOCAL/bin/libntl.dll"
-         if [ ! -f "$SAGE_LOCAL/bin/libntl.dll.a" ]; then
-             exit 1   # CRUCIAL that we have the dynamic link library
-         fi
-```
+The spkg available at
+http://perso.telecom-paristech.fr/~flori/sage/ntl-5.5.2.p0.spkg
+vastly simplifies the old spkg-install, uses the (slightly patched) upstream build system and includes its own version of libtool (or rather the tools needed to generate it on the fly).

[jpflori]

Changed author from Karl-Dieter Crisman to Karl-Dieter Crisman, Jean-Pierre Flori

[jpflori]

comment:47

Ok, the latest spkg built correctly.

Anyone wants to try on Mac OS? or Solaris?

[dimpase]

comment:48

Replying to @jpflori:

Ok, the latest spkg built correctly.

Anyone wants to try on Mac OS? or Solaris?

it works on MacOSX 10.6.8.