Created attachment 275289 [details] Build log Hello there! You're getting this bug because the package in Summary failed to build in my tinderbox using the gold link editor from binutils. Before closing the bug as INVALID let me explain why this is still important! The gold link editor does not support underlinking of shared objects, which is something I have described in my blog post: http://blog.flameeyes.eu/2010/11/26/it-s-not-all-gold-that-shines-why-underlinking-is-a-bad-thing Even the basic link editor (ld.bfd) has an option to support this but it is a heck to enable and get passed, so linking with gold is simply quicker. Fixing underlinking provides optimized --as-needed builds (because the "softer" version no longer need to recover libraries that are underlinked), so it is a Good Thing To Do. Thank you very much for the attention!
Hey Diego, this underlinking issue is very interesting, and it appears that it could, indeed, cause badness. Your blog post does not talk about ways to "fix" it. Is there a way to do such without appealing to upstream (i.e. through a change in flags)? If not, it may be difficult to convince all upstreams to change things to address this.
The only solution is to link properly to the libraries used. In this case it should have -luuid -lcom_err, not just -luuid.
OK, easy enough. BTW, is it just the "convert" program that has this underlinked condition, or others, as well? Currently, we only depend on e2fsprogs if the acl USE flag is set (which builds "convert"), but I'll move it outside the conditional if it affects others as well.
Never mind - build log shows the problem for "convert"... I'll add it there.
I can't easily tell if there are more problems; but if the others built without e2fsprogs then it should work fine.
Fixed and patch sent to upstream
