Patches from Fedora
8 views
Skip to first unread message
Jerry James
Jan 10, 2013, 11:25:29 AM1/10/13
to linbox...@googlegroups.com
Greetings,
I am the primary maintainer for the linbox package in the Fedora Linux distribution. We've recently had to patch linbox in some new ways, due to library updates and a new architecture, so I thought I'd take the opportunity to share the entire set of patches we are currently carrying (attached). All of these patches are against a subversion checkout.
The first patch, linbox-destructor.patch, fixes a problem when building with shared libraries only. If the tests are run in this scenario on a recent glibc, then glibc detects a double free at the end of the test and kills the test program, for all tests. This is because defining LinBoxSrcOnly leads to varioius definitions being inlined into the test program, that were already inlined into the library. With static libraries, this doesn't matter, because the duplicates are merged at link time. With a shared library build, though, the upshot is that the constructors and destructors for the duplicate symbols are executed twice. It turns out that you can get away with executing the constructor twice, but executing the destructor twice doesn't work so well. :-) This patch changes LinBoxSrcOnly to LinBoxTestOnly for the tests, thereby not inlining the troublesome definitions into the test programs.
GCC 4.7 introduced some changes to the C++ lookup rules. See http://gcc.gnu.org/gcc-4.7/changes.html; search for "two-phase lookup". This causes some build failures, which are fixed by linbox-gcc47.patch.
There is a missing semicolon in linbox/field/Modular/modular-int64.h, fixed by linbox-int64.patch.
When building a shared library, liblinbox.so has undefined symbols. This is fixed by linbox-underlink.patch. This may not be desirable for static library builds. I'm not sure how to accommodate both. We actually use a more invasive patch than this, because linbox is also overlinked. That is, some ELF objects wind up linked with libraries that do not resolve any symbols for that object. We insert -Wl,--as-needed into the link line to address this issue, but that is both gcc and GNU ld specific, so I'm not proposing it here.
The driver build currently fails, because rebind() takes one fewer arguments than it did before. This is "fixed" by linbox-driver.patch, but it looks like the driver could use a little more tweaking. I don't consider myself competent to do that tweaking.
Detection of lapack support in fflas-ffpack is currentlly broken due to a typo in a symbol name, fixed with linbox-lapack.patch.
Fedora recently upgraded to FPLLL 4.0.1. This broke building linbox with FPLLL support. FPLLL 3.x and 4.x are sufficiently different that supporting them both may be difficult, but linbox-fplll.patch contains some changes to build with version 4.
Finally, Fedora's s390 team recently tried to build linbox and encountered a problem due to size_t being unsigned long. Dan Horák, suggests linbox-size_t.patch as a fix.
Regards,
--
Jerry James
I am the primary maintainer for the linbox package in the Fedora Linux distribution. We've recently had to patch linbox in some new ways, due to library updates and a new architecture, so I thought I'd take the opportunity to share the entire set of patches we are currently carrying (attached). All of these patches are against a subversion checkout.
The first patch, linbox-destructor.patch, fixes a problem when building with shared libraries only. If the tests are run in this scenario on a recent glibc, then glibc detects a double free at the end of the test and kills the test program, for all tests. This is because defining LinBoxSrcOnly leads to varioius definitions being inlined into the test program, that were already inlined into the library. With static libraries, this doesn't matter, because the duplicates are merged at link time. With a shared library build, though, the upshot is that the constructors and destructors for the duplicate symbols are executed twice. It turns out that you can get away with executing the constructor twice, but executing the destructor twice doesn't work so well. :-) This patch changes LinBoxSrcOnly to LinBoxTestOnly for the tests, thereby not inlining the troublesome definitions into the test programs.
GCC 4.7 introduced some changes to the C++ lookup rules. See http://gcc.gnu.org/gcc-4.7/changes.html; search for "two-phase lookup". This causes some build failures, which are fixed by linbox-gcc47.patch.
There is a missing semicolon in linbox/field/Modular/modular-int64.h, fixed by linbox-int64.patch.
When building a shared library, liblinbox.so has undefined symbols. This is fixed by linbox-underlink.patch. This may not be desirable for static library builds. I'm not sure how to accommodate both. We actually use a more invasive patch than this, because linbox is also overlinked. That is, some ELF objects wind up linked with libraries that do not resolve any symbols for that object. We insert -Wl,--as-needed into the link line to address this issue, but that is both gcc and GNU ld specific, so I'm not proposing it here.
The driver build currently fails, because rebind() takes one fewer arguments than it did before. This is "fixed" by linbox-driver.patch, but it looks like the driver could use a little more tweaking. I don't consider myself competent to do that tweaking.
Detection of lapack support in fflas-ffpack is currentlly broken due to a typo in a symbol name, fixed with linbox-lapack.patch.
Fedora recently upgraded to FPLLL 4.0.1. This broke building linbox with FPLLL support. FPLLL 3.x and 4.x are sufficiently different that supporting them both may be difficult, but linbox-fplll.patch contains some changes to build with version 4.
Finally, Fedora's s390 team recently tried to build linbox and encountered a problem due to size_t being unsigned long. Dan Horák, suggests linbox-size_t.patch as a fix.
Regards,
--
Jerry James
Jean-Guillaume Dumas
May 15, 2013, 8:17:49 AM5/15/13
to linbox...@googlegroups.com, logan...@gmail.com
> suggests linbox-size_t.patch as a fix.
>
> Regards,
Dear J. James,
>
> Regards,
sorry for the delay in answering !
Thank you very much for these patches, we have now put all of them in
the svn; they will be published in the next linbox release.
Best regards,
--
Jean-Guillaume Dumas.
____________________________________________________________________
Jean-Guill...@imag.fr T�l.: +33 476 514 866
Universit� Joseph Fourier, Grenoble I. Fax.: +33 476 631 263
Laboratoire Jean Kuntzmann, Math�matiques Appliqu�es et Informatique
51, avenue des Math�matiques. LJK/IMAG - BP53. 38041 Grenoble FRANCE
http://ljk.imag.fr/membres/Jean-Guillaume.Dumas
____________________________________________________________________
Reply all
Reply to author
Forward
0 new messages