Bug 458658 - Unable to build yaboot with e2fsprogs-devel
Unable to build yaboot with e2fsprogs-devel
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yaboot (Show other bugs)
10
powerpc Linux
high Severity high
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: F10Target
  Show dependency treegraph
 
Reported: 2008-08-11 08:16 EDT by Roman Rakus
Modified: 2014-01-12 19:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:17:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Roman Rakus 2008-08-11 08:16:37 EDT
Description of problem:
Unable to build yaboot with e2fsprogs-devel in rawhide

Version-Release number of selected component (if applicable):
e2fsprogs-devel-1.41.0-1.fc10

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:
Build error

Expected results:
Build ok.

Additional info:
Build log in koji:
http://koji.fedoraproject.org/koji/getfile?taskID=770056&name=build.log

Works with older version in fc9, which is 1.40.
Comment 1 Eric Sandeen 2008-08-11 12:32:34 EDT
Thanks, confirmed (tried building on F9 w/ just the updated e2fsprogs) - not sure what's going on here but will look into it.
Comment 2 Theodore Tso 2008-08-11 12:45:37 EDT
__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.
Comment 3 Eric Sandeen 2008-08-11 13:06:48 EDT
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 ...
Comment 4 Eric Sandeen 2008-08-11 14:05:29 EDT
__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
Comment 5 Eric Sandeen 2008-10-01 00:04:36 EDT
FWIW, this is the upstream commit that changed the behavior:

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

... 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.
Comment 6 Eric Sandeen 2008-10-01 13:23:54 EDT
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...)
Comment 7 Eric Sandeen 2008-10-01 13:37:43 EDT
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
Comment 8 Theodore Tso 2008-10-01 15:06:38 EDT
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.
Comment 9 Eric Sandeen 2008-10-01 15:16:55 EDT
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
Comment 10 Roman Rakus 2008-10-09 08:30:29 EDT
Now the build is done without any changes in yaboot. Any changes in e2fsprogs? I didn't found any...
Comment 11 Eric Sandeen 2008-10-10 11:07:44 EDT
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
Comment 12 Bug Zapper 2008-11-25 21:44:27 EST
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
Comment 13 Bug Zapper 2009-11-18 02:46:03 EST
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
Comment 14 Bug Zapper 2009-12-18 01:17:51 EST
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.

Note You need to log in before you can comment on or make changes to this bug.