On Tue, Aug 9, 2011 at 5:03 PM, Bernhard R. Link <[email protected]> wrote: > * Bastien ROUCARIES <[email protected]> [110808 22:00]: >> Le 8 août 2011 17:45, "Bernhard R. Link" <[email protected]> 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?
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/fpucw >> This approach is only suitable in main program not in library. > > The gnulib approach? Then it would not be interesting for ntl anyway. Yes but a library should not modify fpu control word. >> 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). Not sane. Think about using another lib that need to use long double. It will give bad result see for instance http://sources.redhat.com/bugzilla/show_bug.cgi?id=706 It is well know bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 See example of this kind of bug here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=247465 > The possible problem I see is > the automatic detection by trying the build machine. I thing simply > hardcoding this could be safer. Not safe if your main program link to other library. Another think to try will to compile with -ffloat-store gcc option on i386. It will disable the excess precision. An help her. > >>> * 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? Yes it is > >> 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. Ok will try to get a glimpse a t it tommorow > Bernhard R. Link > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact [email protected] > Archive: > http://lists.debian.org/[email protected] > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAE2SPAYHwQdyzSYHHvEU1yHfsT=+l-2eqtc6mg1elejgwtw...@mail.gmail.com
