I have applications which successfully compile with the -m32 switch (in DMD and/or GCC) to produce:
appname: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.15, not stripped
The source packages I have created work fine, on both 32 bit and 64 bit Ubuntu to build the appropriate binary .debs.
I would like to produce the i386 .deb on the same 64 bit machine i use to produce the 64 bit .deb.
Is this possible, and where should I look for instructions?
The answer depends on the complexity of your build. When the normal 64 bit userland tools suffice for a build, simply specify the architecture via -a
debuild -ai386
However, there are often cases where this doesn't work, and in these cases you'll need pbuilder. pbuilder builds a clean Debian/Ubuntu system in a chroot-ed environment. man pbuilder is a good introduction. To get started, you'll need:
sudo pbuilder --create --architecture i386
sudo pbuilder --build mypackage.dsc
It starts with calling debuild with the -ai386 option, which will
change the architecture that the package is built for.
Of course you have to ensure that the package contains the i386 build of the application.
You don't do anything thing different from building a 64bit .deb. Except that you include a 32bit build of your application.
The control file specifies the architecture, so be sure you select the correct one.
Related
I have installed Debian on qemu 64-bit ARM (followed this tutorial)
uname -a
Linux test 4.9.0-7-arm64 #1 SMP Debian 4.9.110-1 (2018-07-05) aarch64 GNU/Linux
and I am trying to run 32 bit elf files on it, but some work some don't:
bash: ./file_2: cannot execute binary file: Exec format error
running file command on the file that runs, I get:
file_1: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, not stripped
and the one that does not run:
file_2: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically
linked, stripped
and both work on 32bit system(armv7l)
the only difference is that SYSV/ARM version.
is there any work around without recompiling the kernel?(read this post)
As the linked post suggests, this requires CONFIG_COMPAT to be enabled in the kernel. On the other hand I would be surprised if your kernel didn't have it -- the Debian 4.9.0-4 kernel I have from doing that tutorial does set CONFIG_COMPAT. You can check whether your kernel has it enabled by looking at the config file for it which will be in /boot/ in the guest. If it's missing then you need a new kernel, and nothing else will help.
However in your case you do have CONFIG_COMPAT, and some executables work. The difference between the ones that work and the ones that don't is that the working ones are EABI, and the non-working ones are OABI. OABI is an old and obsolete ABI for 32-bit Arm Linux binaries (the "O" stands for "old", and it's been a bad choice for a decade or so...) and it is not supported by the 64-bit kernel's CONFIG_COMPAT. You'll need to rebuild those binaries from source as EABI binaries if you want to run them under a 64-bit kernel.
I'm using Mediatek X20 dev board and gcc-linaro-6.3.1-2017.05 version
for benchmark aarch64 vs aarch32.
So I want to build binaries as 2 types of aarch32 abi : lp64, ilp32.
From gcc manual, (# [toolchain_path]/share/doc/gcc/AArch64-Options.html)
It says I can choose ilp32 and lp64 with -mabi option.
But when I use -mabi=lp64 or -mabi=ilp32, gcc makes error like below.
armv8l-linux-gnueabihf-gcc: error: unrecognized argument in option \u2018-mabi=lp64\u2019
armv8l-linux-gnueabihf-gcc: note: valid arguments to \u2018-mabi=\u2019 are: aapcs aapcs-linux apcs-gnu atpcs iwmmxt
How can I make ilp32 and lp64 formated binary?
And How can I check the binary's format?
Thanks for your reply :)
ILP32 and ILP64 are both AArch64, just one of them is limited to 32-bit addresses, but instruction encoding is the same. For that you will need to use a special toolchain. I have not tried this, but you should Google for "AArch64 ILP32 toolchain". Looks like it's not actively maintained though.
If you want AArch32, that is just ARMv7 and you need the regular arm toolchain (arm-linux-gnueabihf).
https://wiki.linaro.org/Platform/arm64-ilp32
There is now a cross-toolchain for amd64 targetting arm64ilp32 for Debian stable here:
https://people.linaro.org/~wookey/ilp32/
It's very new, but seems to work fine. Note that this targets arm64ilp32 only. If you want to also target normal arm64 (LP64) then you need to also install the aarch64-linux-gnu crosscompiler that is already in the archive.
Feedback is very welcome. The g++ cross-complier is not yet installable because there is no corresponding libstdc++:arm64ilp32 available.
Update (sept 2017). This repo now contains a debootstrappable arm64ilp32 set of packages for Debian stable.
I want to automate expect for passwd but I don't have permission to install.
But if I could copy and paste the expect source code and execute the .c files usingcc/gcc
and generate the executable expect.
or
Can I copy the expect executable from linux and just use it anywhere else like on solaris, aix etc?
This is the expect in /usr/bin/expect in my linux box:
[root#test]# file /usr/bin/expect
/usr/bin/expect: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
The prebuilt executables for Solaris and Linux at kbskit include Expect (along with lots of other Tcl extensions) in the *bi "Batteries Included" versions. Each is just one big file, no unpacking or installing is needed, apart from eg. chmod a+x SunOS_kbsvq8.5-bi to make the file executable. You use this executable to run your script, and at the start of the script you need to add package require Expect to set up the Expect commands.
If you have a C compiler, you can build expect (but you have to build Tcl first).
The executable from Linux can't be used almost anywhere else (on solaris, aix, etc.); there is a chance for it to work on FreeBSD.
If you are on Solaris 11 then installing expect is as easy as:
pkg install //solaris/shell/expect
The package will come from the official Oracle Solaris repository so nothing to worry about. There's no need to get sources, build, etc.
I understand that you may not have permission to do this but since this comes from official source (Oracle) I'm pretty sure your sysadmin will do it in a sec.
I am trying to compile a small utility called tcpslice. It's the typical GNU C application. When I run ./configure, here is the output:
checking build system type... Invalid configuration `x86_64-pc-linux-gnuoldld': machine `x86_64-pc' not recognized
configure: error: /bin/sh ./config.sub x86_64-pc-linux-gnuoldld failed
It appears to not support compilation as a 64-bit Linux application. So I have a few questions:
Is it possible to set some flags to compile the application as 32-bit AND be able to run it on my 64-bit operating system?
Is it possible to update the configure script to support 64-bit Linux? If so, will I be making some serious code changes in the .c files as well?
I noticed a 64-bit RHEL6 machine on my network has this utility installed and running with an identical version number (1.2a3). Could I somehow download the source that was used to build it? I can get access the to RHN if necessary.
Is it possible to set some flags to compile the application as 32-bit AND be able to run it on my 64-bit operating system?
Yes. -m32 is the option.
Is it possible to update the configure script to support 64-bit Linux? If so, will I be making some serious code changes in the .c files as well?
You will have to make some code changes to make a purely 32 bit application work on 64 bit. Here's a link that talks about porting code from 32 bit to 64 bit.
I am sorry, I do not know the answer for your 3rd question.
Hope the little information provided by me helps in some way.
You've misinterpreted what the configure script is telling you. The solution has nothing to do with CPU bitness.
The error comes down to a too-old version of config.guess, which the package creator generated with libtoolize. To fix it, you will need to have libtool installed, then say:
$ libtoolize --force
You'll find that configure now runs, because libtoolize overwrote the tarball version of config.guess with one appropriate to your system.
You may run into another problem, a "missing" bpf.h file. Just edit tcpslice.c and change this line:
#include <net/bpf.h>
to:
#include <pcap-bpf.h>
With those two changes, I got tcpslice to build on my 64-bit CentOS 5 box.
install following packages :
$apt-get install ia32-libs.
for rhel its different :
look at the answer to this question :
CentOS 64 bit bad ELF interpreter
gcc 4.5.1
Fedora 14 Linux
I have this static library that was build from a previous programmer. However, he has left the company and we don't have the source code. All we have is the header files *.h and the libnet.a static library.
When I am try and link this with our application. I get a incompatible linker error. I think the problem is that the static library has been built on a 32 bit machine. And I am trying to link using a 64 bit machine. I could compile my application using the cflag -m32. However, I just want to know if there is any command that will give me if the static library was built in either 32 or 64 bit mode?
Many thanks for any suggestions,
An .a archive is just a collection of objects, so why not:
ar x libnet.a
file someobj.o
That will give you an answer like:
someobj.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Just running file over it could be enough?
opening it up in a hex editor with ascii view may reveal some clues