Seems like the configure script called by mpiblast is not a standard autoconf configure but also calls make. It shouldn't, please avoid that. The reason for it is that we have econf specially taking care of _configure_ failures. Also, this does not properly return an error on failure, so if it fails it tries to rebuild everything during test phase, and then again during install phase, wasting a huge amount of time at build failure time. Additionally, the epatch line is *bad* *bad* *bad* since it does not take into consideration possible mistakes along the line; please avoid something like that.
*** Bug 278194 has been marked as a duplicate of this bug. ***
Hmm it seems like "make" is not called at all, instead the make test/make install seem to produce the build, that fails. I'll consider last riting this unless somebody can fix it soon.
Thanks for reporting. This package has multiple issues, and I agree that the configure script is very bad. The new series (1.6) is in beta and it uses a standard configure script. I've bumped the package to that series, removed old versions, and dropped all keywords. However, the new version only compiles using gcc-4.3 and earlier, and fails with gcc-4.4. I'm unfortunately very short on time so I haven't been able to troubleshoot the compile issue. I would appreciate any help.
Back in April, there was a message posted to their bugs list <http://lists.mpiblast.org/pipermail/bugs_lists.mpiblast.org/2010-April/000006.html> that seems to indicate they shadowed glibc functions, so source fortification is probably reacting badly. Looking at the 1.6.0 source that you linked earlier today, it looks like they did this intentionally in an attempt to capture calls to fprintf. The intercept function appears to be vulnerable to a buffer overflow, as it uses the original fprintf format and arguments to vsprintf to a buffer of fixed size, then checks for success by querying whether the null byte at the end of the fixed size buffer was changed. If the null byte is intact, they then use strlen to compute the length of the printed data, and write that to some other location. It is unclear why they use an unchecked sprintf instead of a checked snprintf, as well as why they assume that sprintf can never generate embedded nulls in the strings it processes. Weaver: please be aware that Diego files hundreds of bugs regarding a variety of problems with packages identified by his tinderbox, so he likely does not have time to offer assistance in fixing individual issues. That said, many Gentoo users lurk in Bugzilla, and some may offer assistance if you identify a specific problem with which you would like help. In this case, if it were my package, I would push this upstream and mask this package until upstream can address the problems more fully. Since the shadowing of fprintf is intentional, I think it would be better to let them explain why they need this shadowed than to just fix the immediate shadowing problem and consider the package ready to go.
Removed from main tree.
