Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 121095
Summary: | [x86_64] grub-0.94-4: binaried linked against 32-bit libraries. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Aleksey Nogin <aleksey> |
Component: | grub | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | 64bit_fedora, axel.thimm, jakub, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-23 17:29:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Aleksey Nogin
2004-04-17 02:02:19 UTC
The problem still exists with grub-0.94-5 P.S. # rpm -Uvh grub-0.94-5.x86_64.rpm error: Failed dependencies: libc.so.6 is needed by grub-0.94-5 libc.so.6(GLIBC_2.0) is needed by grub-0.94-5 libc.so.6(GLIBC_2.1) is needed by grub-0.94-5 libc.so.6(GLIBC_2.2) is needed by grub-0.94-5 libc.so.6(GLIBC_2.3) is needed by grub-0.94-5 # rpm -q --provides glibc | grep libc.so libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.2.6)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) # up2date -u (sudo nogin@matrix41) Password: using mirror: ftp://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/development/x86_64 Fetching Obsoletes list for channel: rawhide... Fetching rpm headers... ######################################## Name Version Rel ---------------------------------------------------------- grub 0.94 5 x86_64 Testing package set / solving RPM inter-dependencies... /etc/security/selinux/file_contexts: No such file or directory ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: The following packages were added to your selection to satisfy dependencies: Name Version Release -------------------------------------------------------------- glibc 2.3.3 27 glibc 2.3.3 27 package glibc-2.3.3-27 is already installed [warren@laptop work]$ file grub-0.94-3/sbin/grub grub-0.94-3/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, statically linked, stripped [warren@laptop work]$ file grub-0.94-5/sbin/grub grub-0.94-5/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped Nothing changed since -3. Both -3 and -5 are 32bit binaries. I recall something about grub on x86_64 needing to be 32bit. I think this is NOTABUG and it does already work properly. Some would consider it is a bug that we require the 32bit glibc to be installed, but in reality x86_64 is really an incomplete system and cumbersome without 32bit. If there is any bug here, it would be that package conflict that you indicate above. I am unable to reproduce that conflict however. Can you explain what is the cause? That actually causes grub installation to fail from up2date? Ack... Sopwith just pointed out that it changed from static to dynamic. I was correct that grub should be 32bit binaries. It appears from the cvs changes that changing from static to dynamic was accidental, but I do not know if this breaks anything. Investigating more... @@ -79,14 +87,17 @@ %patch500 -p1 -b .raid %patch501 -p1 -b .initrdmax +%patch502 -p1 -b .emd + +%patch1000 -p1 -b .26geom %build autoreconf --install --force +CFLAGS="-Os -g" ; export CFLAGS +%configure --sbindir=/sbin --disable-auto-linux-mem-opt %ifarch x86_64 LDFLAGS="-Wl,-static" ; export LDFLAGS %endif -CFLAGS="-Os -g" ; export CFLAGS -%configure --sbindir=/sbin --disable-auto-linux-mem-opt make %install It appears from here that the %configure was intentionally moved above the part where LDFLAGS is set for -static. Something within %configure pulled in the -static flag for the subsequent make. I suspect that changing to dynamic was unintended, because the x86_64 conditional was not removed? In any case I personally tested grub-install on x86_64 extensively on Thursday, Friday, and Saturday while debugging another issue, so it appears that grub is not broken. Sopwith and I belive that the only effect of this would be to pull in 32bit glibc NO MATTER WHAT. Unless somebody can prove that this is a true show-stopper for x86_64 we should target to make it static again for FC3. > If there is any bug here, it would be that package conflict that you > indicate above. I am unable to reproduce that conflict however. Can > you explain what is the cause? That actually causes grub installation > to fail from up2date? # rpm -qa --qf '%{arch}\n'|sort |uniq -c 44 noarch 5 (none) 403 x86_64 # rpm -q grub up2date grub-0.94-3 up2date-4.3.19-1 # up2date grub using mirror: ftp://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/development/x86_64 Fetching Obsoletes list for channel: rawhide... Fetching rpm headers... ######################################## Name Version Rel ---------------------------------------------------------- grub 0.94 5 x86_64 Testing package set / solving RPM inter-dependencies... /etc/security/selinux/file_contexts: No such file or directory ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: The following packages were added to your selection to satisfy dependencies: Name Version Release -------------------------------------------------------------- glibc 2.3.3 27 glibc 2.3.3 27 package glibc-2.3.3-27 is already installed Jeremy, 1) Was it an accident to change grub from static to dynamic? It appears that runtime operation is not broken by this change, but it does guarantee that 32bit glibc is pulled in. 2) Is comment #6 an up2date bug? I don't see that behavior in apt. It was done as otherwise the build breaks as gcc no longer contains a static libgcc.a. With simple hello world -- [katzj@orodruin grub-0.94]$ gcc -m32 -Os -g -Wl,-static -o test test.c /usr/bin/ld: cannot find -lgcc_s_32 collect2: ld returned 1 exit status Jakub -- is there a reason libgcc.a no longer exists? Or a new way of specifying this? It does exist, but -Wl,-static is a serious bug, never use it. -static must be used instead, then it will find everything it needs just fine. Fixed for 0.95-1 Works nicely in FC3t2/x86_64 (and as a side effect allows apt to work on a 32bit clean setup, I'll rebuild for FC2/x86_64, as lack of apt here has been rather painful). I guess you can close this bug. |