How to run 32 bit programs on 64 bit Fedora 17?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
9
down vote

favorite
4












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' ...)







share|improve this question




















  • 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














up vote
9
down vote

favorite
4












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' ...)







share|improve this question




















  • 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












up vote
9
down vote

favorite
4









up vote
9
down vote

favorite
4






4





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' ...)







share|improve this question












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' ...)









share|improve this question











share|improve this question




share|improve this question










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
















  • 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










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]


;)






share|improve this answer






















  • 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










  • 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

















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.






share|improve this answer






















  • 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

















up vote
2
down vote













You can install the necessary package with:



sudo yum install redhat-lsb.i686





share|improve this answer






















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    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






























    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]


    ;)






    share|improve this answer






















    • 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










    • 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














    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]


    ;)






    share|improve this answer






















    • 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










    • 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












    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]


    ;)






    share|improve this answer














    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]


    ;)







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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 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










    • 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










    • 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











    • 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












    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.






    share|improve this answer






















    • 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














    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.






    share|improve this answer






















    • 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












    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.






    share|improve this answer














    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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 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















    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










    up vote
    2
    down vote













    You can install the necessary package with:



    sudo yum install redhat-lsb.i686





    share|improve this answer


























      up vote
      2
      down vote













      You can install the necessary package with:



      sudo yum install redhat-lsb.i686





      share|improve this answer
























        up vote
        2
        down vote










        up vote
        2
        down vote









        You can install the necessary package with:



        sudo yum install redhat-lsb.i686





        share|improve this answer














        You can install the necessary package with:



        sudo yum install redhat-lsb.i686






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Apr 14 '13 at 6:20









        Michael Mrozek♦

        58.3k26184206




        58.3k26184206










        answered Apr 14 '13 at 4:43









        xwindows

        211




        211






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay