I'm trying to run valgrind 32bit binaries on 64 bit machine(linux) and i'm getting this error:
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No
such file or directory
What do i need to do to make it work?
You do not have installed Valgrind for analysing 32-bit programs on your Linux distribution.
For example on Ubuntu 15.04, installing Valgrind via
apt-get install valgrind
installs both 32-bit and 64-bit versions of the Valgrind analytical tools:
$ ls -1 /usr/lib/valgrind/memcheck-*
/usr/lib/valgrind/memcheck-amd64-linux
/usr/lib/valgrind/memcheck-x86-linux
What is you Linux distribution?
I had the same issue and fixed it by setting VALGRIND_LIB to Valgrind's library path (eg. /usr/local/lib/valgrind) in my .bashrc:
export VALGRIND_LIB="/usr/local/lib/valgrind"
I don't know why this is not mentioned in the Valgrind Installation Instructions or why I had to add this following these instructions, however I found this hint in the README_DEVELOPERS shipped with the sources.
Related
When I try to execute a 32-bit file compiled with gcc -m32 main.c -o main on Windows Subsystem for Linux, I get the following error: bash: ./main: cannot execute binary file: Exec format error.
If I compile it without -m32 it runs.
Any solution for running 32-bit executable on WSL?
QEMU and binfmt support light the way :)
https://github.com/microsoft/wsl/issues/2468#issuecomment-374904520
After reading that the WSLInterop between WSL and Windows processes used binfmt, I was tinkering with QEMU to try some ARM development, and incidentally discovered how to get 32-bit support working.
Edit: requires "Fall Creators Update", 1709, build 16299 or newer
Install qemu and binfmt config:
sudo apt install qemu-user-static
sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'
You'll need to reactivate binfmt support every time you start WSL:
sudo service binfmt-support start
Enable i386 architecture packages:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install gcc:i386
Try it out:
$ file /usr/bin/gcc-5
/usr/bin/gcc-5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=2637bb7cb85f8f12b40f03cd015d404930c3c790, stripped
$ /usr/bin/gcc-5 --version
gcc-5 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc helloworld.c -o helloworld
$ ./helloworld
Hello, world!
$ file helloworld
helloworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3a0c7be5c6a8d45613e4ef2b7b3474df6224a5da, not stripped
And to prove it really was working, disable i386 support and try again:
$ sudo service binfmt-support stop
* Disabling additional executable binary formats binfmt-support [ OK ]
$ ./helloworld
-bash: ./helloworld: cannot execute binary file: Exec format error
32-bit ELF support isn't provided by WSL (yet). There doesn't seem to be any progress since the UserVoice was raised - you are out luck.
See UserVoice: Please add 32 bit ELF support to the kernel and Support for 32-bit i386 ELF binaries.
If possible, switch to a real Linux ;-)
Since this was originally posted, the support has been available on WSL2 which does support real Linux kernel! So that should be the preferred way.
As noted in the linked github issue, there's also qemu-user which can be used if WSL1 is still used.
WSL2 runs in a real virtual machine using a real Linux kernel, therefore it's actually possible to do anything a Linux VM can do, including running 32-bit code. Just install 32-bit libs by running
sudo dpkg --add-architecture i386
sudo apt-get update
For more information read
Announcing WSL 2
WSL 2 FAQ
I try to understand the requirements for developing Linux application running on 64-bit OS (with 64-bit architecture).
If the code was written for 32-bits architecture, does it mean that on regular compilation (gcc -m32) it will run on the 64-bit system OS, without any problems ?
Thank you,
Ran
Yes, it will. The only caveats to this are that you need 32 bit libraries to run the program, and 32 bit development packages to compile it. Most distros provide these and make it simple to install them as well.
I am using a software for graph mining.
I have got the binary of that software in 2 folders for Linux mode and SunOs mode but don't have the source.
I am able to run the binary in Linux machine.
But when I want to run the binary in a Mac machine I am getting "command not found" for both the Linux and SunOs folders' binaries.
Could someone suggest if it can be able to run this in a MAC machine by any means like using a Linux shell or something
Gaurav
EDIT:I am getting "cannot execute binary" error when I set chmod to "u+x"
You'll need to recompile it for OS X or use a VM.
A command not found just means you're not executing it right, make sure it's chmod u+x and it's either on your PATH, or you specify the path explicitly.
If you use the file command you will see the difference, on the linux executable you'll have something like:
ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically
linked, for GNU/Linux 2.6.15, not stripped
and something like this for OS X executables:
command: Mach-O universal binary with 2 architectures command (for
architecture x86_64): Mach-O 64-bit executable x86_64 command (for
architecture i386): Mach-O executable i386
Operating systems generally don't support executing object code any extra formats... If Mac osx decended from solaris or Linux, then there could be some incentive for legacy support. But just assume everything to be binarily incomparable if it was compiled for a different arch and platform. There are a few places where you inherit backwards compatibility, running 32 but code on 64 bit oses... Or ppc code support on intel macs, but I suspect that both of those, especially the latter were non trivial engineering tasks.
Here are your options...
Get the source and compile on the Mac, if it compiles on Linux and solaris good chance it will compile and run ok on Mac.
Run through an emulator or boot camp
I've cross-compiled the bulk of my 32-bit code on my x64 Ubuntu install, but I can't work out how to do the same trick with libcurl.
I've tried many permutations of --host and/or --build i486, x86, etc. but none have helped. I've also tried editing the makefiles to include gcc's -m32 flag manually, but it never shows up when I run them.
What should I be doing?
After you download and extract the libcurl source package, as a root user, run this command for setting up the build environment.
configure --host=i686-pc-linux-gnu CFLAGS=-m32 CC=/usr/bin/gcc
followed by
make
you can find the libs under ./lib/.libs/libcurl.so from where you ran the make command.
if you dont find /usr/bin/gcc, you will have to install gcc for 32-bit cross compilation env in a 64-bit machine.
It would help if you gave us an error message. I've had issues on Ubuntu x64 systems compiling 32-bit code with 'ld' errors.. I solved it by adding LDEMULATION=elf_i386 to my environment.
Cheers,
I want to avoid problems with compiling my code on amd64, yet I don't have a 64-bit CPU available and have no hopes of getting upgrade to my machine any time soon. I have no dreams of testing the code (although that should theoretically be possible using qemu-system) but I'd like to at least compile the code using gcc -m64.
Basic idea works:
CFLAGS=-m64 CXXFLAGS=-m64 ./configure --host x86_64-debian-linux
However, the code depends on some libraries which I typically install from Debian packages, such as libsdl1.2-dev, libgmp3-dev and such. Obviously, getting 64-bit versions of packages installed alongside of 32-bit versions is not a one-liner.
What would be your practices for installing the 64-bit packages? Where would you put them, how would you get them there and how would you use them?
To repeat, I don't have 64-bit CPU and cannot afford getting a new machine.
I have already set up amd64-libs-dev to give some basic push to gcc's -m64.
Attempted so far:
Setting up a 64-bit chroot jail with debootstrap in order to simplify installation of 64-bit development packages for libraries. Failed since finishing the setup (and installing anything afterwards!) requires 64-bit CPU.
Installing gcc-multilib and g++-multilib. This appears to do nothing beside depending on libc6-dev-amd64 which I already installed through amd64-libs-dev.
If you're using debian, before you can use gcc -m64, you need to install gcc-multilib and g++-multilib. This will also install all files needed to link and create a 64bit binary.
You don't have to have a 64bit capable CPU for this either.
Then you can call GCC as follows:
$ gcc -m64 source.c -o source
As for external libraries, debian takes care of that if you have multilib installed. I have a 32bit machine that compiles 64bit code for another machine and links a handful of libraries (libpng, libz for example). Works great and the executable run (debian to debian).
You want to look into the dchroot package to set up a simple chroot(8) environment -- that way you can compile real amd64 binaries in a real 64-bit setting with proper libraries and dependencies. This surely works the other way (i.e. I am using i386 chroots on amd64 hosts) but I don't see why it shouldn't work the other way if your cpu supports amd64.
Edit: Now that you stress that you do not have a amd64-capable cpu, it gets a little trickier. "In theory" you could just rebuild gcc from source as a cross-compiler. In practice, that may be too much work. Maybe you can just get another headless box for a few dollars and install amd64 on that?
check out this fine article that describes how to easily create a 32bit chroot, where you can install all the 32bit tools (gcc and libs)
Doesn't Debian distinguish between lib32 and lib64 directories? In that case, you can just grab the packages and force them to install, regardless of architecture.
If that does not work (or would hose your system!) I would set up a chroot environment and apt-get the 64-bit libraries into there.
Check out pbuilder, It can create build environments for many architectures, some instructions here
Try cross compiling SDL, gmp and other libraries yourself. Or manually extract the files you need from the Debain packages.