Re: RE : ntl

["Bernhard R. Link" <brlink@debian.org>]

* Bastien ROUCARIES <roucaries.bastien@gmail.com> [110808 22:00]:
> Le 8 août 2011 17:45, "Bernhard R. Link" <brlink@debian.org> a écrit :
>> Open issues:
>>      * The build process creates a mach_desc.h from testing the
>>        build machine. I'm a bit uneasy about especially one part
>>        of it: register extended doubles.
>>
>>        If it finds those active of the build machine, it adds on
>>        i386/Linux some code to change some register to disable
>>        that behaviour whenever doing operations that might effect.
>>
>>        Does anyone know if those register is garanteed to be set
>>        on i386/Linux? If that is variable, a buildd might not have
>>        set it, thus the setting not compiled in thus the library
>>        producing different behaviour on other machines.
>>
>>        (As I read it, that flag is almost the only one not directly
>>        calculateable from values in limits.h or stdint.h, so it
>>        might make sense to patch that file with a static architecture-
>>        independant variant and just check at compile them whether the
>>        assumptions are true, instead of calculating those at runtime).

> First issue is solved by memory by a gnulib module, it will be better to
> use.

I don't find anything in gnulib documentation. Do you have a pointer?

> This approach is only suitable in main program not in library.

The gnulib approach? Then it would not be interesting for ntl anyway.

> It is a
> well know i386 fpu problem. Another option is to use a special gcc flag
> (floating store) but library will be slower

I think the behaviour ntl is using (some assembler on i386 to unset and
restore the CPU bit to control this behaviour) looks itself sane
(assuming it is inly relevant on i386). The possible problem I see is
the automatic detection by trying the build machine. I thing simply
hardcoding this could be safer.

>>      * Symbol files would be nice. A c++ library isn't the most easy
>>        case, though.
> Second issue is more difficult

Is this the second issue you are refering to or something else?

> Question. What vcs did you use?

http://anonscm.debian.org/gitweb/?p=debian-science/packages/libntl.git;a=summary
The upstreamtarballs is just all the tarballs from upstream's website
imported and "old" is the old .dsc files imported (minus some artefacts
from the .diff files that should never have been there), while
"oldpatched" is the debian/patches/* files imported.

	Bernhard R. Link