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:rw_bitmaps.o:
1.40.10.nm-         U __sprintf_chk

1.41.0.nm:rw_bitmaps.o:
1.41.0.nm-         U __sprintf_chk

FWIW, this is the upstream commit that changed the behavior:

commit a0553c9d6e8dd6f538f18ae447c45e52f3c40eb6
Author: Theodore Ts'o <tytso>
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
    first.

    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" <tytso>

... 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.

Index: yaboot-1.3.13/lib/nosys.c
===================================================================
--- yaboot-1.3.13.orig/lib/nosys.c
+++ yaboot-1.3.13/lib/nosys.c
@@ -1,5 +1,13 @@
+#include "string.h"
+
 /* we got no time */
 long time()
 {
 	return 0;
 }
+
+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 :)

Thanks,
-Eric

(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 @@
 (/usr/lib/libext2fs.a)read_bb.o
 (/usr/lib/libext2fs.a)swapfs.o
 (/usr/lib/libext2fs.a)badblocks.o
-(/usr/lib/libext2fs.a)bitmaps.o
 (/usr/lib/libext2fs.a)dir_iterate.o
-(/usr/lib/libext2fs.a)gen_bitmap.o
-(/usr/lib/libext2fs.a)rw_bitmaps.o
-(/usr/lib/libext2fs.a)bitops.o
 (/usr/lib/libext2fs.a)dirblock.o
 attempt to open /usr/lib/gcc/ppc64-redhat-linux/4.3.2/libgcc.a succeeded
 (/usr/lib/gcc/ppc64-redhat-linux/4.3.2/libgcc.a)_lshrdi3.o

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:

http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commitdiff;h=2d40a91e171ec1cfb6bb80a0e788e0740bb1d747

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

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 ;)

Thanks,
-Eric

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.

-Eric

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.