How to run 32 bit programs on 64 bit Fedora 17?
Clash Royale CLAN TAG#URR8PPP
up vote
9
down vote
favorite
Although the Android Development Tools (ADT) bundle is available as a zip package for 'Linux 64 Bit' it states following requirements:
64-bit distributions must be capable of running 32-bit applications.
And indeed, just running the packaged eclipse on a Fedora 17 64 bit system results in errors, because it can't 'find' several development tools, e.g. adb
or aapt
:
Error executing aapt: Cannot run program "/home/juser/local/adt-bundle-linux/sdk/platform-tools/aapt": error=2, No such file or directory: error=2, No such file or directory
The 'no such file' is misleading because it is there (under $HOME/local):
adt-bundle-linux/sdk/platform-tools/aapt
But I can't execute it on the shell:
~/local $ ./adt-bundle-linux/sdk/platform-tools/aapt
zsh: no such file or directory: ./adt-bundle-linux/sdk/platform-tools/aapt
Looking at the file
$ file adt-bundle-linux/sdk/platform-tools/aapt
adt-bundle-linux/sdk/platform-tools/aapt: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8,
not stripped
we see that it is a 32 binary. And it seems that my system (currently) is not capable of running 32-bit applications.
How do I change that? How do I make a current Fedora 64 bit system capable of running 32 bit applications?
(Of course one could also ask why someone ends up putting 32 bit binaries into a binary package called 'Linux 64 bit' ...)
fedora 64bit android 32bit
add a comment |Â
up vote
9
down vote
favorite
Although the Android Development Tools (ADT) bundle is available as a zip package for 'Linux 64 Bit' it states following requirements:
64-bit distributions must be capable of running 32-bit applications.
And indeed, just running the packaged eclipse on a Fedora 17 64 bit system results in errors, because it can't 'find' several development tools, e.g. adb
or aapt
:
Error executing aapt: Cannot run program "/home/juser/local/adt-bundle-linux/sdk/platform-tools/aapt": error=2, No such file or directory: error=2, No such file or directory
The 'no such file' is misleading because it is there (under $HOME/local):
adt-bundle-linux/sdk/platform-tools/aapt
But I can't execute it on the shell:
~/local $ ./adt-bundle-linux/sdk/platform-tools/aapt
zsh: no such file or directory: ./adt-bundle-linux/sdk/platform-tools/aapt
Looking at the file
$ file adt-bundle-linux/sdk/platform-tools/aapt
adt-bundle-linux/sdk/platform-tools/aapt: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8,
not stripped
we see that it is a 32 binary. And it seems that my system (currently) is not capable of running 32-bit applications.
How do I change that? How do I make a current Fedora 64 bit system capable of running 32 bit applications?
(Of course one could also ask why someone ends up putting 32 bit binaries into a binary package called 'Linux 64 bit' ...)
fedora 64bit android 32bit
Similar question with answer on AskFedora: ask.fedoraproject.org/question/365/â¦
â gertvdijk
Dec 7 '12 at 12:57
To understand why you're getting this message: Getting âÂÂNot foundâ message when running a 32-bit binary on a 64-bit system
â Gilles
Dec 7 '12 at 22:19
add a comment |Â
up vote
9
down vote
favorite
up vote
9
down vote
favorite
Although the Android Development Tools (ADT) bundle is available as a zip package for 'Linux 64 Bit' it states following requirements:
64-bit distributions must be capable of running 32-bit applications.
And indeed, just running the packaged eclipse on a Fedora 17 64 bit system results in errors, because it can't 'find' several development tools, e.g. adb
or aapt
:
Error executing aapt: Cannot run program "/home/juser/local/adt-bundle-linux/sdk/platform-tools/aapt": error=2, No such file or directory: error=2, No such file or directory
The 'no such file' is misleading because it is there (under $HOME/local):
adt-bundle-linux/sdk/platform-tools/aapt
But I can't execute it on the shell:
~/local $ ./adt-bundle-linux/sdk/platform-tools/aapt
zsh: no such file or directory: ./adt-bundle-linux/sdk/platform-tools/aapt
Looking at the file
$ file adt-bundle-linux/sdk/platform-tools/aapt
adt-bundle-linux/sdk/platform-tools/aapt: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8,
not stripped
we see that it is a 32 binary. And it seems that my system (currently) is not capable of running 32-bit applications.
How do I change that? How do I make a current Fedora 64 bit system capable of running 32 bit applications?
(Of course one could also ask why someone ends up putting 32 bit binaries into a binary package called 'Linux 64 bit' ...)
fedora 64bit android 32bit
Although the Android Development Tools (ADT) bundle is available as a zip package for 'Linux 64 Bit' it states following requirements:
64-bit distributions must be capable of running 32-bit applications.
And indeed, just running the packaged eclipse on a Fedora 17 64 bit system results in errors, because it can't 'find' several development tools, e.g. adb
or aapt
:
Error executing aapt: Cannot run program "/home/juser/local/adt-bundle-linux/sdk/platform-tools/aapt": error=2, No such file or directory: error=2, No such file or directory
The 'no such file' is misleading because it is there (under $HOME/local):
adt-bundle-linux/sdk/platform-tools/aapt
But I can't execute it on the shell:
~/local $ ./adt-bundle-linux/sdk/platform-tools/aapt
zsh: no such file or directory: ./adt-bundle-linux/sdk/platform-tools/aapt
Looking at the file
$ file adt-bundle-linux/sdk/platform-tools/aapt
adt-bundle-linux/sdk/platform-tools/aapt: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8,
not stripped
we see that it is a 32 binary. And it seems that my system (currently) is not capable of running 32-bit applications.
How do I change that? How do I make a current Fedora 64 bit system capable of running 32 bit applications?
(Of course one could also ask why someone ends up putting 32 bit binaries into a binary package called 'Linux 64 bit' ...)
fedora 64bit android 32bit
asked Dec 7 '12 at 10:43
maxschlepzig
31.9k30135202
31.9k30135202
Similar question with answer on AskFedora: ask.fedoraproject.org/question/365/â¦
â gertvdijk
Dec 7 '12 at 12:57
To understand why you're getting this message: Getting âÂÂNot foundâ message when running a 32-bit binary on a 64-bit system
â Gilles
Dec 7 '12 at 22:19
add a comment |Â
Similar question with answer on AskFedora: ask.fedoraproject.org/question/365/â¦
â gertvdijk
Dec 7 '12 at 12:57
To understand why you're getting this message: Getting âÂÂNot foundâ message when running a 32-bit binary on a 64-bit system
â Gilles
Dec 7 '12 at 22:19
Similar question with answer on AskFedora: ask.fedoraproject.org/question/365/â¦
â gertvdijk
Dec 7 '12 at 12:57
Similar question with answer on AskFedora: ask.fedoraproject.org/question/365/â¦
â gertvdijk
Dec 7 '12 at 12:57
To understand why you're getting this message: Getting âÂÂNot foundâ message when running a 32-bit binary on a 64-bit system
â Gilles
Dec 7 '12 at 22:19
To understand why you're getting this message: Getting âÂÂNot foundâ message when running a 32-bit binary on a 64-bit system
â Gilles
Dec 7 '12 at 22:19
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
8
down vote
accepted
With regard to eclipse not being able to find adb
, etc, this because without the 32-bit shared libraries needed to run them on the system, they are not executable.
With regard to 32-bit libraries, the situation is fairly simple: you just need to install the appropriate 32-bit libs. On the 64-bit fedora 17 install I have here, the primary 64-bit libraries are in /usr/lib64 and optional 32-bit libs are in /usr/lib. So, if I call ldd
on on sdk/platform-tools/adb:
linux-gate.so.1 => (0xf7791000)
librt.so.1 => /lib/librt.so.1 (0xf776c000)
libncurses.so.5 => /lib/libncurses.so.5 (0xf7747000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf772d000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7644000)
libm.so.6 => /lib/libm.so.6 (0xf7618000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf75fb000)
libc.so.6 => /lib/libc.so.6 (0xf7449000)
/lib/ld-linux.so.2 (0xf7792000)
libdl.so.2 => /lib/libdl.so.2 (0xf7444000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf7424000)
Notice these are all in /lib, which is a symlink to /usr/lib (not /usr/lib64). Look:
ûfile /lib/libc.so.6
/lib/libc.so.6: symbolic link to `libc-2.15.so'
ûfile /lib/libc-2.15.so
/lib/libc-2.15.so: ELF 32-bit LSB shared object [...]
A 32-bit standard C library. What you can do is go through the 32-bit sdk tools and check to see what they are linked against with ldd
. I don't have an example at hand, but if something is missing ldd
reports something like:
libc.so.6 => ??????
First, tho, for ldd to work you will need the 32-bit loader that comes with the 32-bit glibc (without this, ldd will call it a non-executable file and tell you nothing):
ûyum search glibc
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries
That's truncated, but the x86_64 package is what you have already; the i686 is the 32-bit version. So just install that.
You do not need any of the 'devel' packages, as nothing gets compiled. Beyond that, educated guesses and yum whatprovides
/ yum search
should help (looking at the list for adb, there's also 32-bit versions of the C++ lib, ncurses, pthreads, and a I few things I don't know).
Quick tip about using whatprovides
:
ûyum whatprovides libtinfo
No matches found.
ûyum whatprovides libtinfo.so.5
[2 matches]
ûyum whatprovides "*/libtinfo.so.5"
[4 matches]
;)
ok, I'll try to install the i686 versions of libraries displayed vialdd
. For the reason: I am not convinced, callingfile
on the bundle version ofadb
displays: ELF 32-bit LSB executable, Intel 80386 - nothing to do with ARM emulation - and /usr/bin/adb (from the android-tools fedora package) is actually available as ELF 64-bit LSB executable, x86-64.
â maxschlepzig
Dec 7 '12 at 15:16
If I call ldd onadt-bundle-linux/sdk/platform-tools/adb
it displays 'not a dynamic executable'. Regarding the PATH - this is not the problem - fully specifying the path of e.g../adt-bundle-linux/sdk/platform-tools/adb
in a terminal does not work (results in 'zsh: no such file or directory [..]').
â maxschlepzig
Dec 7 '12 at 15:24
Do you have glibc.i686 installed yet? Like I said, you (likely) need a 32-bit loader for ldd to work, and that will be with the glibc package. WRT adb being a 32-bit intel arch, that's because that's your system, something compiled for ARM will not work there. However, the same 32-bit stuff could be compiled for ARM, and I imagine parts of it are when used on Android devices. I admit might be wrong about that being the necessity, but in any case, that's what's available, and it is not really that much of a hassle.
â goldilocks
Dec 7 '12 at 15:42
WRT the path, maybe it is not necessary for eclipse, and (as you say) you may get the same error on the command line if the file cannot be executed anyway. Just get the libs installed, etc, and you will find out.
â goldilocks
Dec 7 '12 at 15:44
2
There's no relation between the emulator being a 32-bit program and the emulated platform having a 32-bit processor. The Android emulator is in fact based on Qemu, which can emulate any of armv7 (32-bit), armv8 (64-bit), x86, amd64, mips, mips64, and many more, regardless of the host architecture.
â Gilles
Dec 7 '12 at 22:24
 |Â
show 2 more comments
up vote
7
down vote
You have to install the 32 bit glibc:
# yum install glibc.i686
This removes the misleading 'no such file or directory' message when trying to execute a 32 bit binary. With that the 64 bit Fedora system is capable of executing 32 bit binaries.
This also removes the misleading 'not a dynamic executable' message of ldd
when calling ldd
on a 32 bit dynamic executable.
Now you have to install missing 32 bit libraries the binaries under adt-bundle-linux/sdk/platform-tools
are linked against:
# yum install zlib.i686 libstdc++.i686 ncurses-libs.i686 libgcc.i686
Thats it.
Background
Some background how to derive the above package names. For example looking at the output of
$ ldd adb
linux-gate.so.1 => (0xf774f000)
librt.so.1 => /lib/librt.so.1 (0xf7725000)
libncurses.so.5 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0xf770b000)
libstdc++.so.6 => not found
libm.so.6 => /lib/libm.so.6 (0xf76df000)
[..]
means, that 2 libraries are still missing for adb.
For each 'not found' we have to lookup the package name, e.g.:
$ yum whatprovides '*libstdc++.so.6'
[..]
libstdc++-4.7.2-2.fc17.i686 : GNU Standard C++ Library
[..]
Now we take the package base name and add '.i686' to it to get the 32 bit version.
This answer is great, especially the first part - indeed installingglibc.i686
allowsldd
to work properly with i386 binaries.
â Krystian
Jan 22 at 13:08
add a comment |Â
up vote
2
down vote
You can install the necessary package with:
sudo yum install redhat-lsb.i686
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
With regard to eclipse not being able to find adb
, etc, this because without the 32-bit shared libraries needed to run them on the system, they are not executable.
With regard to 32-bit libraries, the situation is fairly simple: you just need to install the appropriate 32-bit libs. On the 64-bit fedora 17 install I have here, the primary 64-bit libraries are in /usr/lib64 and optional 32-bit libs are in /usr/lib. So, if I call ldd
on on sdk/platform-tools/adb:
linux-gate.so.1 => (0xf7791000)
librt.so.1 => /lib/librt.so.1 (0xf776c000)
libncurses.so.5 => /lib/libncurses.so.5 (0xf7747000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf772d000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7644000)
libm.so.6 => /lib/libm.so.6 (0xf7618000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf75fb000)
libc.so.6 => /lib/libc.so.6 (0xf7449000)
/lib/ld-linux.so.2 (0xf7792000)
libdl.so.2 => /lib/libdl.so.2 (0xf7444000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf7424000)
Notice these are all in /lib, which is a symlink to /usr/lib (not /usr/lib64). Look:
ûfile /lib/libc.so.6
/lib/libc.so.6: symbolic link to `libc-2.15.so'
ûfile /lib/libc-2.15.so
/lib/libc-2.15.so: ELF 32-bit LSB shared object [...]
A 32-bit standard C library. What you can do is go through the 32-bit sdk tools and check to see what they are linked against with ldd
. I don't have an example at hand, but if something is missing ldd
reports something like:
libc.so.6 => ??????
First, tho, for ldd to work you will need the 32-bit loader that comes with the 32-bit glibc (without this, ldd will call it a non-executable file and tell you nothing):
ûyum search glibc
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries
That's truncated, but the x86_64 package is what you have already; the i686 is the 32-bit version. So just install that.
You do not need any of the 'devel' packages, as nothing gets compiled. Beyond that, educated guesses and yum whatprovides
/ yum search
should help (looking at the list for adb, there's also 32-bit versions of the C++ lib, ncurses, pthreads, and a I few things I don't know).
Quick tip about using whatprovides
:
ûyum whatprovides libtinfo
No matches found.
ûyum whatprovides libtinfo.so.5
[2 matches]
ûyum whatprovides "*/libtinfo.so.5"
[4 matches]
;)
ok, I'll try to install the i686 versions of libraries displayed vialdd
. For the reason: I am not convinced, callingfile
on the bundle version ofadb
displays: ELF 32-bit LSB executable, Intel 80386 - nothing to do with ARM emulation - and /usr/bin/adb (from the android-tools fedora package) is actually available as ELF 64-bit LSB executable, x86-64.
â maxschlepzig
Dec 7 '12 at 15:16
If I call ldd onadt-bundle-linux/sdk/platform-tools/adb
it displays 'not a dynamic executable'. Regarding the PATH - this is not the problem - fully specifying the path of e.g../adt-bundle-linux/sdk/platform-tools/adb
in a terminal does not work (results in 'zsh: no such file or directory [..]').
â maxschlepzig
Dec 7 '12 at 15:24
Do you have glibc.i686 installed yet? Like I said, you (likely) need a 32-bit loader for ldd to work, and that will be with the glibc package. WRT adb being a 32-bit intel arch, that's because that's your system, something compiled for ARM will not work there. However, the same 32-bit stuff could be compiled for ARM, and I imagine parts of it are when used on Android devices. I admit might be wrong about that being the necessity, but in any case, that's what's available, and it is not really that much of a hassle.
â goldilocks
Dec 7 '12 at 15:42
WRT the path, maybe it is not necessary for eclipse, and (as you say) you may get the same error on the command line if the file cannot be executed anyway. Just get the libs installed, etc, and you will find out.
â goldilocks
Dec 7 '12 at 15:44
2
There's no relation between the emulator being a 32-bit program and the emulated platform having a 32-bit processor. The Android emulator is in fact based on Qemu, which can emulate any of armv7 (32-bit), armv8 (64-bit), x86, amd64, mips, mips64, and many more, regardless of the host architecture.
â Gilles
Dec 7 '12 at 22:24
 |Â
show 2 more comments
up vote
8
down vote
accepted
With regard to eclipse not being able to find adb
, etc, this because without the 32-bit shared libraries needed to run them on the system, they are not executable.
With regard to 32-bit libraries, the situation is fairly simple: you just need to install the appropriate 32-bit libs. On the 64-bit fedora 17 install I have here, the primary 64-bit libraries are in /usr/lib64 and optional 32-bit libs are in /usr/lib. So, if I call ldd
on on sdk/platform-tools/adb:
linux-gate.so.1 => (0xf7791000)
librt.so.1 => /lib/librt.so.1 (0xf776c000)
libncurses.so.5 => /lib/libncurses.so.5 (0xf7747000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf772d000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7644000)
libm.so.6 => /lib/libm.so.6 (0xf7618000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf75fb000)
libc.so.6 => /lib/libc.so.6 (0xf7449000)
/lib/ld-linux.so.2 (0xf7792000)
libdl.so.2 => /lib/libdl.so.2 (0xf7444000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf7424000)
Notice these are all in /lib, which is a symlink to /usr/lib (not /usr/lib64). Look:
ûfile /lib/libc.so.6
/lib/libc.so.6: symbolic link to `libc-2.15.so'
ûfile /lib/libc-2.15.so
/lib/libc-2.15.so: ELF 32-bit LSB shared object [...]
A 32-bit standard C library. What you can do is go through the 32-bit sdk tools and check to see what they are linked against with ldd
. I don't have an example at hand, but if something is missing ldd
reports something like:
libc.so.6 => ??????
First, tho, for ldd to work you will need the 32-bit loader that comes with the 32-bit glibc (without this, ldd will call it a non-executable file and tell you nothing):
ûyum search glibc
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries
That's truncated, but the x86_64 package is what you have already; the i686 is the 32-bit version. So just install that.
You do not need any of the 'devel' packages, as nothing gets compiled. Beyond that, educated guesses and yum whatprovides
/ yum search
should help (looking at the list for adb, there's also 32-bit versions of the C++ lib, ncurses, pthreads, and a I few things I don't know).
Quick tip about using whatprovides
:
ûyum whatprovides libtinfo
No matches found.
ûyum whatprovides libtinfo.so.5
[2 matches]
ûyum whatprovides "*/libtinfo.so.5"
[4 matches]
;)
ok, I'll try to install the i686 versions of libraries displayed vialdd
. For the reason: I am not convinced, callingfile
on the bundle version ofadb
displays: ELF 32-bit LSB executable, Intel 80386 - nothing to do with ARM emulation - and /usr/bin/adb (from the android-tools fedora package) is actually available as ELF 64-bit LSB executable, x86-64.
â maxschlepzig
Dec 7 '12 at 15:16
If I call ldd onadt-bundle-linux/sdk/platform-tools/adb
it displays 'not a dynamic executable'. Regarding the PATH - this is not the problem - fully specifying the path of e.g../adt-bundle-linux/sdk/platform-tools/adb
in a terminal does not work (results in 'zsh: no such file or directory [..]').
â maxschlepzig
Dec 7 '12 at 15:24
Do you have glibc.i686 installed yet? Like I said, you (likely) need a 32-bit loader for ldd to work, and that will be with the glibc package. WRT adb being a 32-bit intel arch, that's because that's your system, something compiled for ARM will not work there. However, the same 32-bit stuff could be compiled for ARM, and I imagine parts of it are when used on Android devices. I admit might be wrong about that being the necessity, but in any case, that's what's available, and it is not really that much of a hassle.
â goldilocks
Dec 7 '12 at 15:42
WRT the path, maybe it is not necessary for eclipse, and (as you say) you may get the same error on the command line if the file cannot be executed anyway. Just get the libs installed, etc, and you will find out.
â goldilocks
Dec 7 '12 at 15:44
2
There's no relation between the emulator being a 32-bit program and the emulated platform having a 32-bit processor. The Android emulator is in fact based on Qemu, which can emulate any of armv7 (32-bit), armv8 (64-bit), x86, amd64, mips, mips64, and many more, regardless of the host architecture.
â Gilles
Dec 7 '12 at 22:24
 |Â
show 2 more comments
up vote
8
down vote
accepted
up vote
8
down vote
accepted
With regard to eclipse not being able to find adb
, etc, this because without the 32-bit shared libraries needed to run them on the system, they are not executable.
With regard to 32-bit libraries, the situation is fairly simple: you just need to install the appropriate 32-bit libs. On the 64-bit fedora 17 install I have here, the primary 64-bit libraries are in /usr/lib64 and optional 32-bit libs are in /usr/lib. So, if I call ldd
on on sdk/platform-tools/adb:
linux-gate.so.1 => (0xf7791000)
librt.so.1 => /lib/librt.so.1 (0xf776c000)
libncurses.so.5 => /lib/libncurses.so.5 (0xf7747000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf772d000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7644000)
libm.so.6 => /lib/libm.so.6 (0xf7618000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf75fb000)
libc.so.6 => /lib/libc.so.6 (0xf7449000)
/lib/ld-linux.so.2 (0xf7792000)
libdl.so.2 => /lib/libdl.so.2 (0xf7444000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf7424000)
Notice these are all in /lib, which is a symlink to /usr/lib (not /usr/lib64). Look:
ûfile /lib/libc.so.6
/lib/libc.so.6: symbolic link to `libc-2.15.so'
ûfile /lib/libc-2.15.so
/lib/libc-2.15.so: ELF 32-bit LSB shared object [...]
A 32-bit standard C library. What you can do is go through the 32-bit sdk tools and check to see what they are linked against with ldd
. I don't have an example at hand, but if something is missing ldd
reports something like:
libc.so.6 => ??????
First, tho, for ldd to work you will need the 32-bit loader that comes with the 32-bit glibc (without this, ldd will call it a non-executable file and tell you nothing):
ûyum search glibc
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries
That's truncated, but the x86_64 package is what you have already; the i686 is the 32-bit version. So just install that.
You do not need any of the 'devel' packages, as nothing gets compiled. Beyond that, educated guesses and yum whatprovides
/ yum search
should help (looking at the list for adb, there's also 32-bit versions of the C++ lib, ncurses, pthreads, and a I few things I don't know).
Quick tip about using whatprovides
:
ûyum whatprovides libtinfo
No matches found.
ûyum whatprovides libtinfo.so.5
[2 matches]
ûyum whatprovides "*/libtinfo.so.5"
[4 matches]
;)
With regard to eclipse not being able to find adb
, etc, this because without the 32-bit shared libraries needed to run them on the system, they are not executable.
With regard to 32-bit libraries, the situation is fairly simple: you just need to install the appropriate 32-bit libs. On the 64-bit fedora 17 install I have here, the primary 64-bit libraries are in /usr/lib64 and optional 32-bit libs are in /usr/lib. So, if I call ldd
on on sdk/platform-tools/adb:
linux-gate.so.1 => (0xf7791000)
librt.so.1 => /lib/librt.so.1 (0xf776c000)
libncurses.so.5 => /lib/libncurses.so.5 (0xf7747000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf772d000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7644000)
libm.so.6 => /lib/libm.so.6 (0xf7618000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf75fb000)
libc.so.6 => /lib/libc.so.6 (0xf7449000)
/lib/ld-linux.so.2 (0xf7792000)
libdl.so.2 => /lib/libdl.so.2 (0xf7444000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf7424000)
Notice these are all in /lib, which is a symlink to /usr/lib (not /usr/lib64). Look:
ûfile /lib/libc.so.6
/lib/libc.so.6: symbolic link to `libc-2.15.so'
ûfile /lib/libc-2.15.so
/lib/libc-2.15.so: ELF 32-bit LSB shared object [...]
A 32-bit standard C library. What you can do is go through the 32-bit sdk tools and check to see what they are linked against with ldd
. I don't have an example at hand, but if something is missing ldd
reports something like:
libc.so.6 => ??????
First, tho, for ldd to work you will need the 32-bit loader that comes with the 32-bit glibc (without this, ldd will call it a non-executable file and tell you nothing):
ûyum search glibc
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries
That's truncated, but the x86_64 package is what you have already; the i686 is the 32-bit version. So just install that.
You do not need any of the 'devel' packages, as nothing gets compiled. Beyond that, educated guesses and yum whatprovides
/ yum search
should help (looking at the list for adb, there's also 32-bit versions of the C++ lib, ncurses, pthreads, and a I few things I don't know).
Quick tip about using whatprovides
:
ûyum whatprovides libtinfo
No matches found.
ûyum whatprovides libtinfo.so.5
[2 matches]
ûyum whatprovides "*/libtinfo.so.5"
[4 matches]
;)
edited Dec 8 '12 at 15:09
answered Dec 7 '12 at 11:49
goldilocks
59.6k13138194
59.6k13138194
ok, I'll try to install the i686 versions of libraries displayed vialdd
. For the reason: I am not convinced, callingfile
on the bundle version ofadb
displays: ELF 32-bit LSB executable, Intel 80386 - nothing to do with ARM emulation - and /usr/bin/adb (from the android-tools fedora package) is actually available as ELF 64-bit LSB executable, x86-64.
â maxschlepzig
Dec 7 '12 at 15:16
If I call ldd onadt-bundle-linux/sdk/platform-tools/adb
it displays 'not a dynamic executable'. Regarding the PATH - this is not the problem - fully specifying the path of e.g../adt-bundle-linux/sdk/platform-tools/adb
in a terminal does not work (results in 'zsh: no such file or directory [..]').
â maxschlepzig
Dec 7 '12 at 15:24
Do you have glibc.i686 installed yet? Like I said, you (likely) need a 32-bit loader for ldd to work, and that will be with the glibc package. WRT adb being a 32-bit intel arch, that's because that's your system, something compiled for ARM will not work there. However, the same 32-bit stuff could be compiled for ARM, and I imagine parts of it are when used on Android devices. I admit might be wrong about that being the necessity, but in any case, that's what's available, and it is not really that much of a hassle.
â goldilocks
Dec 7 '12 at 15:42
WRT the path, maybe it is not necessary for eclipse, and (as you say) you may get the same error on the command line if the file cannot be executed anyway. Just get the libs installed, etc, and you will find out.
â goldilocks
Dec 7 '12 at 15:44
2
There's no relation between the emulator being a 32-bit program and the emulated platform having a 32-bit processor. The Android emulator is in fact based on Qemu, which can emulate any of armv7 (32-bit), armv8 (64-bit), x86, amd64, mips, mips64, and many more, regardless of the host architecture.
â Gilles
Dec 7 '12 at 22:24
 |Â
show 2 more comments
ok, I'll try to install the i686 versions of libraries displayed vialdd
. For the reason: I am not convinced, callingfile
on the bundle version ofadb
displays: ELF 32-bit LSB executable, Intel 80386 - nothing to do with ARM emulation - and /usr/bin/adb (from the android-tools fedora package) is actually available as ELF 64-bit LSB executable, x86-64.
â maxschlepzig
Dec 7 '12 at 15:16
If I call ldd onadt-bundle-linux/sdk/platform-tools/adb
it displays 'not a dynamic executable'. Regarding the PATH - this is not the problem - fully specifying the path of e.g../adt-bundle-linux/sdk/platform-tools/adb
in a terminal does not work (results in 'zsh: no such file or directory [..]').
â maxschlepzig
Dec 7 '12 at 15:24
Do you have glibc.i686 installed yet? Like I said, you (likely) need a 32-bit loader for ldd to work, and that will be with the glibc package. WRT adb being a 32-bit intel arch, that's because that's your system, something compiled for ARM will not work there. However, the same 32-bit stuff could be compiled for ARM, and I imagine parts of it are when used on Android devices. I admit might be wrong about that being the necessity, but in any case, that's what's available, and it is not really that much of a hassle.
â goldilocks
Dec 7 '12 at 15:42
WRT the path, maybe it is not necessary for eclipse, and (as you say) you may get the same error on the command line if the file cannot be executed anyway. Just get the libs installed, etc, and you will find out.
â goldilocks
Dec 7 '12 at 15:44
2
There's no relation between the emulator being a 32-bit program and the emulated platform having a 32-bit processor. The Android emulator is in fact based on Qemu, which can emulate any of armv7 (32-bit), armv8 (64-bit), x86, amd64, mips, mips64, and many more, regardless of the host architecture.
â Gilles
Dec 7 '12 at 22:24
ok, I'll try to install the i686 versions of libraries displayed via
ldd
. For the reason: I am not convinced, calling file
on the bundle version of adb
displays: ELF 32-bit LSB executable, Intel 80386 - nothing to do with ARM emulation - and /usr/bin/adb (from the android-tools fedora package) is actually available as ELF 64-bit LSB executable, x86-64.â maxschlepzig
Dec 7 '12 at 15:16
ok, I'll try to install the i686 versions of libraries displayed via
ldd
. For the reason: I am not convinced, calling file
on the bundle version of adb
displays: ELF 32-bit LSB executable, Intel 80386 - nothing to do with ARM emulation - and /usr/bin/adb (from the android-tools fedora package) is actually available as ELF 64-bit LSB executable, x86-64.â maxschlepzig
Dec 7 '12 at 15:16
If I call ldd on
adt-bundle-linux/sdk/platform-tools/adb
it displays 'not a dynamic executable'. Regarding the PATH - this is not the problem - fully specifying the path of e.g. ./adt-bundle-linux/sdk/platform-tools/adb
in a terminal does not work (results in 'zsh: no such file or directory [..]').â maxschlepzig
Dec 7 '12 at 15:24
If I call ldd on
adt-bundle-linux/sdk/platform-tools/adb
it displays 'not a dynamic executable'. Regarding the PATH - this is not the problem - fully specifying the path of e.g. ./adt-bundle-linux/sdk/platform-tools/adb
in a terminal does not work (results in 'zsh: no such file or directory [..]').â maxschlepzig
Dec 7 '12 at 15:24
Do you have glibc.i686 installed yet? Like I said, you (likely) need a 32-bit loader for ldd to work, and that will be with the glibc package. WRT adb being a 32-bit intel arch, that's because that's your system, something compiled for ARM will not work there. However, the same 32-bit stuff could be compiled for ARM, and I imagine parts of it are when used on Android devices. I admit might be wrong about that being the necessity, but in any case, that's what's available, and it is not really that much of a hassle.
â goldilocks
Dec 7 '12 at 15:42
Do you have glibc.i686 installed yet? Like I said, you (likely) need a 32-bit loader for ldd to work, and that will be with the glibc package. WRT adb being a 32-bit intel arch, that's because that's your system, something compiled for ARM will not work there. However, the same 32-bit stuff could be compiled for ARM, and I imagine parts of it are when used on Android devices. I admit might be wrong about that being the necessity, but in any case, that's what's available, and it is not really that much of a hassle.
â goldilocks
Dec 7 '12 at 15:42
WRT the path, maybe it is not necessary for eclipse, and (as you say) you may get the same error on the command line if the file cannot be executed anyway. Just get the libs installed, etc, and you will find out.
â goldilocks
Dec 7 '12 at 15:44
WRT the path, maybe it is not necessary for eclipse, and (as you say) you may get the same error on the command line if the file cannot be executed anyway. Just get the libs installed, etc, and you will find out.
â goldilocks
Dec 7 '12 at 15:44
2
2
There's no relation between the emulator being a 32-bit program and the emulated platform having a 32-bit processor. The Android emulator is in fact based on Qemu, which can emulate any of armv7 (32-bit), armv8 (64-bit), x86, amd64, mips, mips64, and many more, regardless of the host architecture.
â Gilles
Dec 7 '12 at 22:24
There's no relation between the emulator being a 32-bit program and the emulated platform having a 32-bit processor. The Android emulator is in fact based on Qemu, which can emulate any of armv7 (32-bit), armv8 (64-bit), x86, amd64, mips, mips64, and many more, regardless of the host architecture.
â Gilles
Dec 7 '12 at 22:24
 |Â
show 2 more comments
up vote
7
down vote
You have to install the 32 bit glibc:
# yum install glibc.i686
This removes the misleading 'no such file or directory' message when trying to execute a 32 bit binary. With that the 64 bit Fedora system is capable of executing 32 bit binaries.
This also removes the misleading 'not a dynamic executable' message of ldd
when calling ldd
on a 32 bit dynamic executable.
Now you have to install missing 32 bit libraries the binaries under adt-bundle-linux/sdk/platform-tools
are linked against:
# yum install zlib.i686 libstdc++.i686 ncurses-libs.i686 libgcc.i686
Thats it.
Background
Some background how to derive the above package names. For example looking at the output of
$ ldd adb
linux-gate.so.1 => (0xf774f000)
librt.so.1 => /lib/librt.so.1 (0xf7725000)
libncurses.so.5 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0xf770b000)
libstdc++.so.6 => not found
libm.so.6 => /lib/libm.so.6 (0xf76df000)
[..]
means, that 2 libraries are still missing for adb.
For each 'not found' we have to lookup the package name, e.g.:
$ yum whatprovides '*libstdc++.so.6'
[..]
libstdc++-4.7.2-2.fc17.i686 : GNU Standard C++ Library
[..]
Now we take the package base name and add '.i686' to it to get the 32 bit version.
This answer is great, especially the first part - indeed installingglibc.i686
allowsldd
to work properly with i386 binaries.
â Krystian
Jan 22 at 13:08
add a comment |Â
up vote
7
down vote
You have to install the 32 bit glibc:
# yum install glibc.i686
This removes the misleading 'no such file or directory' message when trying to execute a 32 bit binary. With that the 64 bit Fedora system is capable of executing 32 bit binaries.
This also removes the misleading 'not a dynamic executable' message of ldd
when calling ldd
on a 32 bit dynamic executable.
Now you have to install missing 32 bit libraries the binaries under adt-bundle-linux/sdk/platform-tools
are linked against:
# yum install zlib.i686 libstdc++.i686 ncurses-libs.i686 libgcc.i686
Thats it.
Background
Some background how to derive the above package names. For example looking at the output of
$ ldd adb
linux-gate.so.1 => (0xf774f000)
librt.so.1 => /lib/librt.so.1 (0xf7725000)
libncurses.so.5 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0xf770b000)
libstdc++.so.6 => not found
libm.so.6 => /lib/libm.so.6 (0xf76df000)
[..]
means, that 2 libraries are still missing for adb.
For each 'not found' we have to lookup the package name, e.g.:
$ yum whatprovides '*libstdc++.so.6'
[..]
libstdc++-4.7.2-2.fc17.i686 : GNU Standard C++ Library
[..]
Now we take the package base name and add '.i686' to it to get the 32 bit version.
This answer is great, especially the first part - indeed installingglibc.i686
allowsldd
to work properly with i386 binaries.
â Krystian
Jan 22 at 13:08
add a comment |Â
up vote
7
down vote
up vote
7
down vote
You have to install the 32 bit glibc:
# yum install glibc.i686
This removes the misleading 'no such file or directory' message when trying to execute a 32 bit binary. With that the 64 bit Fedora system is capable of executing 32 bit binaries.
This also removes the misleading 'not a dynamic executable' message of ldd
when calling ldd
on a 32 bit dynamic executable.
Now you have to install missing 32 bit libraries the binaries under adt-bundle-linux/sdk/platform-tools
are linked against:
# yum install zlib.i686 libstdc++.i686 ncurses-libs.i686 libgcc.i686
Thats it.
Background
Some background how to derive the above package names. For example looking at the output of
$ ldd adb
linux-gate.so.1 => (0xf774f000)
librt.so.1 => /lib/librt.so.1 (0xf7725000)
libncurses.so.5 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0xf770b000)
libstdc++.so.6 => not found
libm.so.6 => /lib/libm.so.6 (0xf76df000)
[..]
means, that 2 libraries are still missing for adb.
For each 'not found' we have to lookup the package name, e.g.:
$ yum whatprovides '*libstdc++.so.6'
[..]
libstdc++-4.7.2-2.fc17.i686 : GNU Standard C++ Library
[..]
Now we take the package base name and add '.i686' to it to get the 32 bit version.
You have to install the 32 bit glibc:
# yum install glibc.i686
This removes the misleading 'no such file or directory' message when trying to execute a 32 bit binary. With that the 64 bit Fedora system is capable of executing 32 bit binaries.
This also removes the misleading 'not a dynamic executable' message of ldd
when calling ldd
on a 32 bit dynamic executable.
Now you have to install missing 32 bit libraries the binaries under adt-bundle-linux/sdk/platform-tools
are linked against:
# yum install zlib.i686 libstdc++.i686 ncurses-libs.i686 libgcc.i686
Thats it.
Background
Some background how to derive the above package names. For example looking at the output of
$ ldd adb
linux-gate.so.1 => (0xf774f000)
librt.so.1 => /lib/librt.so.1 (0xf7725000)
libncurses.so.5 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0xf770b000)
libstdc++.so.6 => not found
libm.so.6 => /lib/libm.so.6 (0xf76df000)
[..]
means, that 2 libraries are still missing for adb.
For each 'not found' we have to lookup the package name, e.g.:
$ yum whatprovides '*libstdc++.so.6'
[..]
libstdc++-4.7.2-2.fc17.i686 : GNU Standard C++ Library
[..]
Now we take the package base name and add '.i686' to it to get the 32 bit version.
edited Sep 10 '15 at 7:25
answered Dec 7 '12 at 17:21
maxschlepzig
31.9k30135202
31.9k30135202
This answer is great, especially the first part - indeed installingglibc.i686
allowsldd
to work properly with i386 binaries.
â Krystian
Jan 22 at 13:08
add a comment |Â
This answer is great, especially the first part - indeed installingglibc.i686
allowsldd
to work properly with i386 binaries.
â Krystian
Jan 22 at 13:08
This answer is great, especially the first part - indeed installing
glibc.i686
allows ldd
to work properly with i386 binaries.â Krystian
Jan 22 at 13:08
This answer is great, especially the first part - indeed installing
glibc.i686
allows ldd
to work properly with i386 binaries.â Krystian
Jan 22 at 13:08
add a comment |Â
up vote
2
down vote
You can install the necessary package with:
sudo yum install redhat-lsb.i686
add a comment |Â
up vote
2
down vote
You can install the necessary package with:
sudo yum install redhat-lsb.i686
add a comment |Â
up vote
2
down vote
up vote
2
down vote
You can install the necessary package with:
sudo yum install redhat-lsb.i686
You can install the necessary package with:
sudo yum install redhat-lsb.i686
edited Apr 14 '13 at 6:20
Michael Mrozekâ¦
58.3k26184206
58.3k26184206
answered Apr 14 '13 at 4:43
xwindows
211
211
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f57863%2fhow-to-run-32-bit-programs-on-64-bit-fedora-17%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Similar question with answer on AskFedora: ask.fedoraproject.org/question/365/â¦
â gertvdijk
Dec 7 '12 at 12:57
To understand why you're getting this message: Getting âÂÂNot foundâ message when running a 32-bit binary on a 64-bit system
â Gilles
Dec 7 '12 at 22:19