Bug 121095 - [x86_64] grub-0.94-4: binaried linked against 32-bit libraries.
[x86_64] grub-0.94-4: binaried linked against 32-bit libraries.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: grub (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-16 22:02 EDT by Aleksey Nogin
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-23 13:29:14 EDT
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 Aleksey Nogin 2004-04-16 22:02:19 EDT
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.
Comment 1 Aleksey Nogin 2004-05-13 04:39:20 EDT
The problem still exists with grub-0.94-5
Comment 2 Aleksey Nogin 2004-05-13 04:45:06 EDT
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
Comment 3 Warren Togami 2004-05-13 05:39:45 EDT
[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?
Comment 4 Warren Togami 2004-05-13 05:48:51 EDT
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...
Comment 5 Warren Togami 2004-05-13 06:07:05 EDT
@@ -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.
Comment 6 Aleksey Nogin 2004-05-13 18:45:02 EDT
> 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
Comment 7 Warren Togami 2004-05-15 00:49:49 EDT
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. 
Comment 8 Jeremy Katz 2004-06-04 18:10:47 EDT
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?
Comment 9 Jakub Jelinek 2004-06-07 16:25:46 EDT
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.
Comment 10 Jeremy Katz 2004-06-18 17:57:00 EDT
Fixed for 0.95-1
Comment 11 Axel Thimm 2004-09-23 13:27:54 EDT
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.

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