Red Hat Bugzilla – Bug 458658
Unable to build yaboot with e2fsprogs-devel
Last modified: 2014-01-12 19:07:44 EST
Description of problem:
Unable to build yaboot with e2fsprogs-devel in rawhide
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Build log in koji:
Works with older version in fc9, which is 1.40.
Thanks, confirmed (tried building on F9 w/ just the updated e2fsprogs) - not sure what's going on here but will look into it.
__sprintf_check is supposed to be defined in libc, and it is emitted by gcc. My guess is that this is a function of the version of gcc used to build the e2fsprogs 1.40 library versus what is now being used to build 1.41, but the real problem is that in order ot be compatible with the version of gcc now in Fedora, yaboot needs to define in its environment all of the *_chk functions that gcc is now emitting.
So this is not an e2fsprogs bug, but a yaboot bug.
Ted, it didn't seem to be an e2fsprogs bug to me either, except that if I put e2fsprogs-1.40.10 (built with f9's gcc) on an F9 box yaboot builds, and if I put e2fsprogs-1.41.0 on the box (also built with f9's gcc), yaboot fails to build. So it doesn't seem to be a gcc mismatch or even a new gcc issue.
So at a minimum, wherever the bug lies, it seems at least to be tickled by the latest version of e2fsprogs ...
__sprintf_chk is U in both versions of the e2fsprogs lib, as well:
1.40.10.nm- U __sprintf_chk
1.41.0.nm- U __sprintf_chk
FWIW, this is the upstream commit that changed the behavior:
Author: Theodore Ts'o <email@example.com>
Date: Sun Jul 22 22:59:50 2007 -0400
libext2fs: 32-bit bitmap refactorization, part 1
Move the 32-bit specific bitmap code into gen_bitmap.c, and the
high-level interfaces into bitmaps.c. Eventually we'll move the
new-style bitmap code into gen_bitmap64.c, but first we need to
isolate the code with knowledge of the bitmap internals in one place
In this patch we move allocation, free, copy, clear, set_padding, and
fudge_end function into gen_bitmap.c, and make sure that the bitmaps.c
and bitops.c no longer have any knowledge of the bitmap internals.
Signed-off-by: "Theodore Ts'o" <firstname.lastname@example.org>
... not saying it's a bug.
This thing is driving me nuts though, still not seeing what has changed which should lead to the build failure.
It's not an issue with changing gcc.
Something like this gets it going, and I think it's not too crazy :)
Here I'm assuming that the _chk function returns 0 on success.
@@ -1,5 +1,13 @@
/* we got no time */
+int __sprintf_chk(char *__restrict __s, int __flag, size_t __slen,
+ __const char *__restrict __format, ...)
+ return 0;
My best guess is that because yaboot has defined its own sprintf etc in lib/* then glibc's versions (and hence the fortify checks around them) are not getting pulled in.
I think yaboot was just lucky before that somehow e2fsprogs inlined this or something... I'm going to punt this back to yaboot for now, but we can continue the discussion if you feel that's wrong :)
(FWIW: differences in ld --verbose output:
--- /tmp/ld-verbose-fail 2008-10-01 12:27:01.922075780 -0400
+++ /tmp/ld-verbose-pass 2008-10-01 12:28:07.026077177 -0400
@@ -315,11 +315,7 @@
attempt to open /usr/lib/gcc/ppc64-redhat-linux/4.3.2/libgcc.a succeeded
so the difference seems to be that in the failing libext2fs.a, with the aforementioned commit in place, it is pulling rw_bitmaps.o into the library, which contains the read_bitmaps() function, which calls sprintf(), which leads to the __sprintf_chk problem... but in the end I think it's yaboot's redefinition of sprintf that is likely the root cause...)
Hm. On the other hand:
also fixes the problem (see also http://sourceforge.net/tracker/index.php?func=detail&aid=2049120&group_id=2406&atid=102406)
At this point I'm not sure what the root cause is, here.
Eric, I think you're on target with the root cause in comment #6. My fix simply removed the use of sprintf, which works around the problem by simply avoiding the use of sprintf altogether. In practice if libext2fs can avoid using sprintf/printf altogether, it can make the resulting statically linked binary smaller, so it can be justified on that grounds as well; but it was also the easist way of fixing this problem with yaboot that was causing everyone to complain.
Just FWIW, comment #6 is functionally busted; it actually needs to call sprintf :) (check is check+do, in reality)
But all this may have given me another reason to go to 1.41.1 sooner than later ;)
Now the build is done without any changes in yaboot. Any changes in e2fsprogs? I didn't found any...
Yes, see comment #7 - this happens to fix it.
I think yaboot is still on slightly thin ice here, but it works for now.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.