In the grub-0.94-4.x86_64 all the binaries (/sbin/grub, etc) seem to be linked against the 32-bit libraries, not the 64-bit ones. The -3 did not have this problem.
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.