i have a prebuilt cross-compile toolchain which, when i try to compile a simple "hi, world", complains thusly:
/bin/bash: prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
since i'm running f11 x86_64, which compat package would i install to get that 32-bit linker? thanks.
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca Linked In: http://www.linkedin.com/in/rpjday Twitter: http://twitter.com/rpjday ========================================================================
2009/5/20 Robert P. J. Day:
i have a prebuilt cross-compile toolchain which, when i try to compile a simple "hi, world", complains thusly:
/bin/bash: prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
since i'm running f11 x86_64, which compat package would i install to get that 32-bit linker? thanks.
yum install /lib/ld-linux.so.2
Should install glibc.i686.
On Wed, 20 May 2009, Paul Black wrote:
2009/5/20 Robert P. J. Day:
i have a prebuilt cross-compile toolchain which, when i try to compile a simple "hi, world", complains thusly:
/bin/bash: prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
since i'm running f11 x86_64, which compat package would i install to get that 32-bit linker? thanks.
yum install /lib/ld-linux.so.2
Should install glibc.i686.
ok, now i feel like an idiot as i had no idea that i could point yum at individual files and have it do the work for me. learn something every day.
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca Linked In: http://www.linkedin.com/in/rpjday Twitter: http://twitter.com/rpjday ========================================================================
Paul Black wrote:
2009/5/20 Robert P. J. Day:
i have a prebuilt cross-compile toolchain which, when i try to compile a simple "hi, world", complains thusly:
/bin/bash: prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
since i'm running f11 x86_64, which compat package would i install to get that 32-bit linker? thanks.
yum install /lib/ld-linux.so.2
Should install glibc.i686.
Okay, we have glibc.x86_64, glibc.i686 installed and glibc.i586 available, why 586 and 686, I thought all the 386 became 586?
Bill Davidsen wrote:
Paul Black wrote:
2009/5/20 Robert P. J. Day:
i have a prebuilt cross-compile toolchain which, when i try to compile a simple "hi, world", complains thusly:
/bin/bash: prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
since i'm running f11 x86_64, which compat package would i install to get that 32-bit linker? thanks.
yum install /lib/ld-linux.so.2
Should install glibc.i686.
Okay, we have glibc.x86_64, glibc.i686 installed and glibc.i586 available, why 586 and 686, I thought all the 386 became 586?
Oh, and the i586 and i686 can't be in at the same time.
On 05/20/2009 04:51 PM, Bill Davidsen wrote:
Okay, we have glibc.x86_64, glibc.i686 installed and glibc.i586 available, why 586 and 686, I thought all the 386 became 586?
Oh, and the i586 and i686 can't be in at the same time.
Glibc is a relatively special case, where the compiler optimizations used to compile it can actually have a significant effect across the system, even if the other items are not compiled with the same set of optimizations.
So, to sum it up simply:
On 32-bit x86 === Pick One: * i586 (good) * i686 (better, but only if your hardware supports i686)
On 64-bit x86_64 === Pick one: * x86_64 (only option)
On a Multilib system (32bit and 64bit libs installed side by side) === * Pick One from the 32-bit x86 list (i586 or i686) * Pick One from the 64-bit x86_64 list (x86_64)
This gets even more complicated on sparc, be glad you're on x86! :)
~spot
2009/5/20 Tom "spot" Callaway:
On 32-bit x86
Pick One:
- i586 (good)
- i686 (better, but only if your hardware supports i686)
<snip>
On a Multilib system (32bit and 64bit libs installed side by side)
- Pick One from the 32-bit x86 list (i586 or i686)
- Pick One from the 64-bit x86_64 list (x86_64)
If, on a 32-bit system, it's better to have the i686 version if possible, why is there an i586 version for 64-bit systems?
2009/5/21 Paul Black paul-fedora@saturnine.org.uk:
2009/5/20 Tom "spot" Callaway:
On 32-bit x86
Pick One:
- i586 (good)
- i686 (better, but only if your hardware supports i686)
<snip>
On a Multilib system (32bit and 64bit libs installed side by side)
- Pick One from the 32-bit x86 list (i586 or i686)
- Pick One from the 64-bit x86_64 list (x86_64)
If, on a 32-bit system, it's better to have the i686 version if possible, why is there an i586 version for 64-bit systems?
If i remember right its because 32bit libs in the 64bit repo are simply copies (or hardlinks) of the 32bit repo. Therefore everything that is in the 32bit repo is in the 64bit repo including glibc.i586 which makes it a possible choice despite the fact that nobody would deliberately choose i586 over i686 on x86_64 since most (if not all) x86_64 support i686.
On Thursday 21 May 2009 16:22:35 John5342 wrote:
If i remember right its because 32bit libs in the 64bit repo are simply copies (or hardlinks) of the 32bit repo. Therefore everything that is in the 32bit repo is in the 64bit repo including glibc.i586 which makes it a possible choice despite the fact that nobody would deliberately choose i586 over i686 on x86_64 since most (if not all) x86_64 support i686.
If you're intending on running an GUI application using 32-bit libs, you may also need to install some X components.
su -c 'yum install glibc.i686 libXext.i586' should see to both, including dependencies.
Steve
Tom "spot" Callaway wrote:
On 05/20/2009 04:51 PM, Bill Davidsen wrote:
Okay, we have glibc.x86_64, glibc.i686 installed and glibc.i586 available, why 586 and 686, I thought all the 386 became 586?
Oh, and the i586 and i686 can't be in at the same time.
Glibc is a relatively special case, where the compiler optimizations used to compile it can actually have a significant effect across the system, even if the other items are not compiled with the same set of optimizations.
So, to sum it up simply:
On 32-bit x86
Pick One:
- i586 (good)
- i686 (better, but only if your hardware supports i686)
On 64-bit x86_64
Pick one:
- x86_64 (only option)
On a Multilib system (32bit and 64bit libs installed side by side)
- Pick One from the 32-bit x86 list (i586 or i686)
- Pick One from the 64-bit x86_64 list (x86_64)
This gets even more complicated on sparc, be glad you're on x86! :)
Thanks, you have clarified it and I'm keeping a copy in my folder of stuff I send people when they ask me questions I've eventually answered.
But the package I really want to use is still looking for the .i586 version, and the other stuff I have will use that, and performance is not an issue compared to network and display slowness.
Steve Dowe wrote:
If you're intending on running an GUI application using 32-bit libs, you may also need to install some X components.
su -c 'yum install glibc.i686 libXext.i586' should see to both, including dependencies.
I did try erasing glibc.i686 and installing glibc.i586, that got all of the programs but one going. One is still whining, I just haven't had time to chase it yet, but I think that the two of you have defined the issues well enough to get me to a solution eventually when I bang on it one more time. I suspect that removing more i686 and dropping to i586 will do the job.
Thanks to both of you, and the other folks who offered suggestions, I appreciate the thought.
Bill Davidsen wrote:
But the package I really want to use is still looking for the .i586 version, and the other stuff I have will use that, and performance is not an issue compared to network and display slowness.
Huh? glibc.i686 is supposed to be a drop-in replacement for glibc.i586. Many 32-bit systems use the i686 build (only).
Kevin Kofler
Kevin Kofler wrote:
Bill Davidsen wrote:
But the package I really want to use is still looking for the .i586 version, and the other stuff I have will use that, and performance is not an issue compared to network and display slowness.
Huh? glibc.i686 is supposed to be a drop-in replacement for glibc.i586. Many 32-bit systems use the i686 build (only).
The original issue is that I have packages which are available in binary form which use the 32 bit ".i585" libraries. And since several are (a) huge, (b) updated frequently, and (c) not known to be 64 bit functional, I find the path of best use is to avoid porting and building them when I can fight the battle of libraries once and be done with it.
I may not have made that clear, or due to the age of the thread you may have forgotten by now.
Bill Davidsen wrote:
The original issue is that I have packages which are available in binary form which use the 32 bit ".i585" libraries.
You didn't get my point. glibc.i586 and glibc.i686 contain the SAME libraries, just differently optimized. All the packages in Fedora get built against one or the other and actually run on both. The same should be true for any third-party binaries. I don't see how which one you pick would make any difference.
And since several are (a) huge, (b) updated frequently, and (c) not known to be 64 bit functional
That doesn't mean they need glibc.i586 rather than glibc.i686.
The right glibc multilib for x86_64 systems is i686, not i586.
Kevin Kofler
Kevin Kofler wrote:
Bill Davidsen wrote:
The original issue is that I have packages which are available in binary form which use the 32 bit ".i585" libraries.
You didn't get my point. glibc.i586 and glibc.i686 contain the SAME libraries, just differently optimized. All the packages in Fedora get built against one or the other and actually run on both. The same should be true for any third-party binaries. I don't see how which one you pick would make any difference.
And since several are (a) huge, (b) updated frequently, and (c) not known to be 64 bit functional
That doesn't mean they need glibc.i586 rather than glibc.i686.
The right glibc multilib for x86_64 systems is i686, not i586.
In spite of all the theory on Earth, packages did not work with i686, removed i686 installed i586, packages work. All packages but one, when I tried installing the 32 bit parts of X and gtk I got conflicts. At that point I just gave up and went 32 bit, the object is to use the system, not chase bugs. I get no benefit from 64 bit, and it was fun trying, getting the 32 bit binaries working takes more (unpaid) time than I have.
I appreciate the comments on 586 vs. 686 I just can't collaborate with experimental data.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/20/2009 12:44 PM, Robert P. J. Day wrote:
i have a prebuilt cross-compile toolchain which, when i try to compile a simple "hi, world", complains thusly:
/bin/bash: prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
since i'm running f11 x86_64, which compat package would i install to get that 32-bit linker? thanks.
rday
Try
yum provides /lib/ld-linux.so.2
Kevin
- -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
-
Bill Davidsen -
John5342 -
Kevin DeKorte -
Kevin Kofler -
Paul Black -
Robert P. J. Day -
Steve Dowe -
Tom Callaway