The programmer put a #include in the wrong place and the problem only occurs when you aren't compiling md5.c for testing. I am actually uncertain of the real outcome of this issue, although it's likely to cause nasties in some form or another.
Created attachment 124520 [details] fdupes-1.40-r1.ebuild new ebuild to fix the problem
Created attachment 124521 [details, diff] fdupes-1.40-md5.c.patch
Oh yea, I've only tested this on Gentoo/amd64, but the problem is pretty straight forward.
Created attachment 124593 [details] fdupes-1.40-r1.ebuild Adds md5sum-external use flag to cause fdupes to use an eternal md5sum executable rather than it's bundled md5 routines. I know there's some stuff that should go in the manifest.xml and probably the ChangeLog, sorry I haven't learned all of that yet.
Well, the outcome is simple: It causes segfaults on 64bit architectures. @Daniel: Did you report the bug to upstream?
(In reply to comment #5) > Well, the outcome is simple: It causes segfaults on 64bit architectures. > > @Daniel: Did you report the bug to upstream? Well, I did now :) I figured it would do something nasty like that. So how do I make sure that fixes like this actually make it into the main portage tree in the future?
(In reply to comment #4) > Created an attachment (id=124593) [edit] > fdupes-1.40-r1.ebuild > > Adds md5sum-external use flag to cause fdupes to use an eternal md5sum > executable rather than it's bundled md5 routines. I know there's some stuff > that should go in the manifest.xml and probably the ChangeLog, sorry I haven't > learned all of that yet. > Sounds like this should be a separate bug.
(In reply to comment #7) > (In reply to comment #4) > > Created an attachment (id=124593) [edit] > > fdupes-1.40-r1.ebuild > > > > Adds md5sum-external use flag to cause fdupes to use an eternal md5sum > > executable rather than it's bundled md5 routines. I know there's some stuff > > that should go in the manifest.xml and probably the ChangeLog, sorry I haven't > > learned all of that yet. > > > > Sounds like this should be a separate bug. > Separate bug for the new use flag or not, the patch to fix this segfaulting bug has has been here since last July, half a year ago, and it still isn't in the portage tree. The new use flag is an enhancement that adds support for one of the features in the configure script. Use the older ebuild if you want, but it would be nice if the user community could get access to patches that work a bit sooner after they are documented and submitted.
oh, I forgot to mention that using an external md5sum program would also work-around the issue, although you can't use that feature with the ebuild in its current state because that feature isn't supported.
Tiziano what did cause segfaults on amd64? patch or usage of external program? Daniel, please, show us the errors you experience and steps to reproduce the problem. At first glance string.h seems to be in correct place as all str*() are used only inside #ifdef TEST ... #endif block.
Daniel, drop my last comment. I was obviously wrong there. I did not manage to reproduce any segfalts on amd64 with this patch, so I've applied it in fdupes-1.40-r1. In fdupes-1.40-r2 I've added md5sum-external USE flag... Thank you for your work. FIXED.
(In reply to comment #11) > Daniel, drop my last comment. I was obviously wrong there. I did not manage to > reproduce any segfalts on amd64 with this patch, so I've applied it in > fdupes-1.40-r1. In fdupes-1.40-r2 I've added md5sum-external USE flag... Thank > you for your work. FIXED. > hurray! :)
