In short: how do I get Squeak 5 to run on x64 Linux?
I dont care whether the executable is 32 or 64 bit as long as it runs and opens the Squeak 5 image.
Here is what I tried:
When I try to run the executables from the Squeak 5 package i get: Running 32-bit Squeak on a 64-bit System. install-libs32 may install them - tried that. Wasn't found.
Then I went looking for a 64 bit executable. There are some from Squeak 4 but they can't open Squeak 5 images.
Looking through the Squeak 5 package:
The shell scripts squeak.sh in both these directories:
Squeak-5.0-All-in-One/
Squeak-5.0-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/
Both return this error:
/usr/bin/ldd didn't produce any output and the system is 64 bit. You may need to (re)install the 32-bit libraries.
There are also misleading files named squeak (no .sh) in these directories:
Squeak-5.0-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-i686
Squeak-5.0-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-i686/bin
They are not the executable, just more shell scripts.
There is another squeak file in:
Squeak-5.0-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-i686/lib/squeak/5.0-3397
Running ./squeak misleadingly says No such file or directory. It is misleading because the file does exist, it is just a 32-bit exe.
file squeak tells me: ELF 32-bit LSB executable, Intel 80386.
So how do I get it to run on 64-bit Linux? I could compile it myself but haven't tried assuming there are a lot of dependencies. Or has anyone tried it?
You already got all information you need:
You may need to (re)install the 32-bit libraries.
Squeak 5 is currently 32bit only. Hence, you need 32bit libraries.
It cannot use your 64bit libraries.
You may need thes:e packages (I use Debian/Ubuntu names, CentOS/RH/SuSE should be similar):
libc6:i386
libuuid1:i386
libkrb5-3:i386
libk5crypto3:i386
zlib1g:i386
libcomerr2:i386
libkrb5support0:i386
libkeyutils1:i386
libx11-6:i386
libgl1-mesa-glx:i386
libsm6:i386
libssl1.0.0:i386
(note the :i386 in the names)
This works in 64 bit Ubuntu 16.04:
In the directory where you unzipped the
Squeak-5.0-All-in-One.zip
archive, and that contains the squeak.sh file,
put the following into a file named libs32.sh :
#!/bin/bash
objdump -p ./Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-i686/lib/squeak/5.0-3397/*|
grep NEEDED|
awk '{print $2}'|
sort -u|
xargs dpkg -S|
awk '{print $1}'|
sort -u|
sed 's/:amd64:/:i386:/'|
sort -u|
sed 's/:$//'
Make that file executable:
chmod +x ./libs32.sh
Run it:
./libs32.sh
You will get a list of libraries that need to be installed.
Run
./lib32.sh | xargs sudo apt install
to see what would be installed.
Run
./lib32.sh | xargs sudo apt install -y
to install it.
Related
I have just installed Cygwin on my 64 bit Windows 10. I need sys/types.h, sys/socket.h and several other libraries. However, I can't find these files under the cygwin installation directory. Where can I get them?
Those are part of the cygwin-devel package:
$ apt-cyg listfiles cygwin-devel | egrep 'sys/(types|socket).h'
usr/include/sys/types.h
usr/include/sys/socket.h
I'm trying to do CMU's binary bomb as an independent project to learn some x86 Assembly and reverse engineering. (It's not an auto-graded version tied to a class.)
I downloaded bomb.tar from http://csapp.cs.cmu.edu/public/labs.html.
From CMU's lab description:
A "binary bomb" is a program provided to students as an object code
file. When run, it prompts the user to type in 6 different strings. If
any of these is incorrect, the bomb "explodes," printing an error
message and logging the event on a grading server. Students must
"defuse" their own unique bomb by disassembling and reverse
engineering the program to determine what the 6 strings should be. The
lab teaches students to understand assembly language, and also forces
them to learn how to use a debugger. It's also great fun. A legendary
lab among the CMU undergrads.
Here's a Linux/IA32 binary bomb that you can try out for yourself. The
feature that notifies the grading server has been disabled, so feel
free to explode this bomb with impunity.
After saving it into an appropriate folder I ran this command in the Terminal:
tar xvf bomb.tar
It did extract a file called bomb (no file extension), but I thought it would also give me bomb.c, which would also be helpful for reference.
I can't get "bomb" to run. Here's what I've tried:
bomb
bomb: command not found
./bomb
bash: ./bomb: No such file or directory
While I realize solving it requires stepping through it in gdb, I can't even run it in BASH and blow myself up with wrong answers yet! A little help would be fantastic.
As the other answers have suggested, this appears to a CPU architecture compatibility issue. I was able to resolve this on Ubuntu 15.04 64-bit by installing the packages located at AskUbuntu.com How to run 32-bit programs on a 64-bit system [duplicate]
Specifically, the following command helped.
sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0
Since Fabio A. Correa ran file on the bomb and found out that it was a 32-bit LSB executable, it seems that is is caused by some missing LSB scripts which should be loaded at startup.
Simply running sudo apt-get install lsb-core will fix this. After doing so, ldd bomb will also work.
Update:
Further ldd (after getting the LSB things ready) shows that it is actually caused by some inexist libc.so.6 => /lib32/libc.so.6, which is the libc of the i386 architecture. You can try installing the libc6-i386 package directly instead.
After that, you can run disassemble func_name in your gdb directly. With all the symbols preserved, you can see the names of the functions directly. strings might help you too.
Btw, this question should be placed in Unix&Linux, I guess.
file bomb informs:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped
You should be able to run it on bash by typing:
tar xvf bomb.tar
chmod +x bomb
./bomb
It worked in my 64-bit Kubuntu 14.04.
My 32-bit application is running under Wine, and to help it better integrate with the environment, it runs some shell scripts. I was just testing under Ubuntu 14.04 64-bit, and my program crashed with this error:
err:process:create_process starting 64-bit process L"Z:\\bin\\sh" not supported in 32-bit wineprefix
I've tried searching for a 32-bit build of "sh" on my system, but couldn't find one. Any creative ideas on how I can get past this issue?
I am a user of the program in question and I did some experimenting with it.
Not 32-bit vs. 64-bit but "shared object" vs. "executable" ?
Running file /bin/dash it prints:
/bin/dash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), ...
Running file /bin/bash however prints:
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), ...
dash is a "shared object" while bash is an "executable". Clearly /bin/dash seems to work like an executable in some way (I don't know the technical details here), but it seems that this difference matters to Wine.
I got the same error as you reported (can't start 64 bit process) for Wine 1.4, but the error I got on newer versions of Wine was wine: Bad EXE format for Z:\bin\sh..
If you actually just replace /bin/sh with /bin/bash (even though that's a 64-bit binary) it will work. Wine also didn't seem to like running a symlink, but copying over /bin/bash worked.
So first back up the existing (symlinked) /bin/sh with:
sudo cp /bin/sh /bin/sh_orig
Then copy bash to sh:
sudo cp /bin/bash /bin/sh
Then when I ran Wine with the program and its calls to /bin/sh work fine.
Alternatively, you download a 32-bit shell directly
Pull down the .deb file for the 32-bit bash shell:
wget http://us.archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.3-6ubuntu1_i386.deb
I your home directory, extract it into a folder:
mkdir ~/bash_4.3-6ubuntu1_i386
dpkg -x bash_4.3-6ubuntu1_i386.deb ~/bash_4.3-6ubuntu1_i386
Copy the bash script into /bin/sh:
sudo mv /bin/sh /bin/sh64original
sudo cp ~/bash_4.3-6ubuntu1_i386/bin/bash /bin/sh
sudo chown root:root /bin/sh
Or run schroot, but still must copy /bin/bash to /bin/sh
Basile Starynkevitch mentioned above about setting up a 32-bit shell in an schroot environment. I did that with an Ubuntu 14.04 32-bit environment and ran into the same issue with the dash vs. bash "shared object" vs. "executable" (but when I copied /bin/bash to /bin/sh it worked), so that helped me realize that the distinction wasn't the 32-bit vs. 64-bit difference but the format of the shell executables that mattered to Wine.
If you would like I can post details for setting up the schroot evnironment but basically I followed the instructions at https://help.ubuntu.com/community/DebootstrapChroot but needed to configure the /etc/apt/sources.list to have the full list of packages (as are installed in my default host system) for apt-get install wine to work.
I'm doing some testing of 64-bit GHC on Windows, in tandem with migrating code forward to GHC 7.6.1. This means that I have both the 32-bit and 64-bit versions of GHC 7.6.1 installed, so I can distinguish 64-bit specific problems from general problems with 7.6.1.
My cabal config file ($APPDATA/cabal/config) contains
libsubdir: $pkgid\$compiler
which means that both 32-bit and 64-bit versions of packages I install are ending up in e.g. zip-archive-0.1.1.8/ghc-7.6.1, and overwriting each other.
Is there any variable like $compiler but distinguishing 32 and 64 bit, or other technique I can use to get it to keep the packages apart?
You can use $arch (and/or $os) with recent enough Cabal versions, which will be replaced by a string such as x86_64 (see Cabal documentation section "Path variables in the simple build system" for more details)
This is probably not the Right Way to do it, but on my laptop where I boot into 32-bit and 64-bit operating systems I have a hack set up to deal with this. Basically, I have two directories, .cabal-i386 and .cabal-x86_64, and I switch back and forth via symlinks. In my .zshrc:
CabalDir=$HOME/.cabal-`uname -m`
if [ ! -d $CabalDir]; then
echo WARNING: no cabal directory yet for `uname -m`, creating one.
mkdir -p $CabalDir/{bin,lib,logs,share}
fi
ln -sft $HOME/.cabal $CabalDir/{bin,lib,logs,share}
Perhaps you can adopt some similar strategy, giving yourself a short command to switch out some symlinks (or whatever Windows' analog of symlinks is).
Following the Linux from Scratch book I have managed to build a toolchain for an ARM on
an ARM. This is till chapter 6 of the book, and on the ARM board itself I could go on further with no problems.
My question is if I can use the prepared environment to continue building the soft from chapter 6 on my x86_64 Fedora 16 laptop?
I thought that while I have all the binaries set up I could just copy them to laptop, chroot inside and feel myself as on the ARM board, but using the command from the book gives no result:
`# chroot "$LFS" /tools/bin/env -i HOME=/root TERM="$TERM" PS1='\u:\w\$
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin /tools/bin/bash --login +h
chroot: failed to run command `/tools/bin/env': No such file or directory`
The binary is there, but it doesn't belong to this system:
`# ldd /tools/bin/env
not a dynamic executable`
The binary is compiled as per the book:
# readelf -l /tools/bin/env | grep interpreter
[Requesting program interpreter: /tools/lib/ld-linux.so.3]
So I wonder if there is a way, like using proper environment variables for CC LD READELF, to continue building for ARM using these tools on x86_64 host.
Thank you.
Yes, you certainly can chroot into an ARM rootfs on an x86 box.
Basically, like this:
$ sudo chroot /path/to/arm/rootfs /bin/sh
sh-4.3# ls --version 2>&1 | head
/bin/ls: unrecognized option '--version'
BusyBox v1.22.1 (2017-03-02 15:41:43 CST) multi-call binary.
Usage: ls [-1AaCxdLHRFplinsehrSXvctu] [-w WIDTH] [FILE]...
List directory contents
-1 One column output
-a Include entries which start with .
-A Like -a, but exclude . and ..
sh-4.3# ls
bin css dev home media proc sbin usr wav
boot data etc lib mnt qemu-arm sys var
My rootfs is for a small embedded device, so everything is BusyBox-based.
How is this working? Firstly, I have the binfmt-misc support running in the kernel. I didn't have to do anything; it came with Ubuntu 18. When the kernel sees an ARM binary, it hands it off to the registered interpreter /usr/bin/qemu-arm-static.
A static executable by that name is found inside my rootfs:
sh-4.3# ls /usr/bin/q*
/usr/bin/qemu-arm-static
I got it from a Ubuntu package. I installed:
$ apt-get install qemu-user-static
and then copied /usr/bin/qemu-arm-static into the usr/bin subdirectory of the rootfs tree.
That's it; now I can chroot into that rootfs without even mentioning QEMU on the chroot command line.
Nope. You can't run ARM binaries on x86, so you can't enter its chroot. No amount of environment variables will change that.
You might be able to continue the process by creating a filesystem image for the target and running it under an emulator (e.g, qemu-system-arm), but that's quite a different thing.
No you cannot, at least not using chroot. What you have in your hands is a toolchain with an ARM target for an ARM host. Binaries are directly executable only on architectures compatible with their host architecture - and x86_64 is not ARM-compatible.
That said, you might be able to use an emulated environment. qemu, for example, offers two emulation modes for ARM: qemu-system-arm that emulates a whole ARM-based system and qemu-arm that uses ARM-native libraries to provide a thinner emulation layer for running ARM Linux executables on non-ARM hosts.