Sorry for top post (from my phone) First issue is solved by memory by a gnulib module, it will be better to use. This approach is only suitable in main program not in library. It is a well know i386 fpu problem. Another option is to use a special gcc flag (floating store) but library will be slower
Second issue is more difficult Question. What vcs did you use? Bastien Le 8 août 2011 17:45, "Bernhard R. Link" <[email protected]> a écrit : * Bernhard R. Link <[email protected]> [110808 17:12]: > The branch, master has been created > at bac15db8073856e14e20eaecdc5423eaf404cdc8 (commit) > - Shortlog ------------------------------------------------------------ > commit bac15db8073856e14e20eaecdc5423eaf404cdc8 > Author: Bernhard R. Link <[email protected]> > Date: Mon Aug 8 17:05:56 2011 +0200 > > Preview packaging of ntl 5.5.2 > > - named source package differently (to allow it and the previous > version to stay around at the same time for some time) > - upstream uses libtool with proper soname, so it's libntl0 now > - changed -dev name (temporarily) to avoid confusion with old -dev package > - repackage using plain debhelper instead of cdbs > - add multiarch support > - "3.0 (quilt)" format source package I've uploaded something to have a basis of discussion (and so someone wanting to look at other packages has already something to base the work on). As upstream now used libtool with --version-info, so hopefully will get proper soname handling, thus the binary package is now libntl0 (as the soname is libntl.so.0). I've changed the source name to libntl and the -dev package name to libntl0-dev to avoid any conflicts with the version currently in Debian. (I think if this will reach Debian it should at least get the -dev back to libntl-dev). It's compiled using libgmp but not gf2x (that isn't yet in Debian or have I overlooked it?). The patches seem to be all upstream or have something similar upstream, so I guess all but the one from the last NMU are no longer needed. Some files still need updating/adding: debian/copyright debian/watch debian/libntl0-dev.doc-base 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). * Symbol files would be nice. A c++ library isn't the most easy case, though. 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]
