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.