5

I'm trying to create an amd64 package using:

sudo dpkg-buildpackage -us -uc -aamd64

on an i386 machine.

The error I get is: 

Can't exec "x86_64-linux-gnu-strip": no such file or directory at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 215

Any suggestions?

Amir Rachum
  • 76,817
  • 74
  • 166
  • 248
Andy Thomas
  • 1,219
  • 3
  • 19
  • 33

3 Answers3

2

Building a cross compiler/binutils is often very hard, and it doesn't allow you to test your programs.
Virtual machines are very slow and create a strong separation which make hard to share files between the host an the VM.

The fastest solution and KISS way is Qemu-User-static : system-calls are translated in 32-bits in user mode. A 64-bits kernel does the same for 32-bits apps (but in kernel mode).

Download or extract a rootfs from a 64-bits Debian livecd.
Copy it to a sub-folder of you real root directory.
Copy qemu-user-x86_64 to a folder of $PATH relative to the fresh extracted rootfs.
copy /etc/resolv.conf to /your_path_to_target/etc/resolv.conf Chroot to it by executing /bin/bash.
Launch apt-get for installing the necessary tools.
Use the rootfs as if you were using a real 64-bits machine.

Things became very simple : Many libraries don't compile because of things like hard-coded paths (you'll face many; many problems like the one you have with cross-compiling). Here all happen as if you build packages natively and the executables were IA-32.

If you are using an x86_64 CPU along a 64-bit kernel, you can skip the whole qemu part. Just extract a 64-bits rootfs and chroot to it : it will be the fastest possible solution which can exist and dpkg-buildpackage will always work (no need to use tools like pbuilder).
Don't forget to copy /etc/resolv.conf if you want to use networking inside chroot.

.

If you use a 32-bits kernel on a 64-bits system, you can use qemu-kvm with a modified bios it will be faster than qemu-user because no JIT recompilation is required.

user2284570
  • 2,891
  • 3
  • 26
  • 74
  • "Virtual machines are very slow". That may be too broad. These days you could just use LXC (as eg via docker) which is likely faster than qemu too. – Dirk Eddelbuettel May 03 '14 at 23:58
  • They can be fast, and *very fast* with hardware support as long as the hypervisor is designed only for running machines with the same instruction-set. If you start to use virtual machines for an architecture the host processor can't run natively, it will be *slow*, very **slow**. For this purpose, a virtual machine require to emulate the full hardware and instruction-set (irq;interrupts...); qemu-user use the host kernel for those tasks. The last time, I used emulated a 300 bogomips mips32 processor on an recent i5-core : it was running slower than on the real hardware (which had 50 bogomips). – user2284570 May 04 '14 at 00:14
  • Hence the appeal of Linux Containers (LXC): "Containers are a lightweight virtualization technology. They are more akin to an enhanced chroot than to full virtualization like Qemu or VMware, both because they do not emulate hardware and because containers share the same operating system as the host." From [here](https://help.ubuntu.com/14.04/serverguide/lxc.html). Looking forward to working more with docker.io myself. – Dirk Eddelbuettel May 04 '14 at 00:19
  • That's just like a slower chroot *(with others features like security and quotas)*. Both LXC and chroot are part of [Operating system–level virtualization](https://en.wikipedia.org/wiki/operating_system–level_virtualization#Implementations). – user2284570 May 04 '14 at 00:29
  • We actually need timings. I don't buy the slower and want to see benchmarks. Know any? – Dirk Eddelbuettel May 04 '14 at 00:31
  • 1
    @DirkEddelbuettel : I recognize that's based on guesses. First, their are many strong separations like limitation on shared memory. LXC heavy rely on a linux kernel feature : cgroups. The purpose is to bring the traditional single-PID Unix limitations *(like CPU % quotas)* to group of process. The linux implementation of `chroot()` don't provide any security and can run on a linux kernel compiled without any security/quotas features. As LXC rely on `chroot()`, it is possible to [break out of it](https://www.google.fr/search?client=opera&q=break+out+of+chroot+jail). – user2284570 May 05 '14 at 19:05
  • @DirkEddelbuettel Please remember that if the kernel is 32 Bits only, it won’t run 64 bits applications. – user2284570 May 10 '19 at 21:37
0

There are a number of ways you could use. Many Debian developers use pbuilder which operates out of a chroot you can create with speficic tools -- a quick google search lead me to this Ubuntu wiki page but there are also Debian wiki pages on it.

An alternative is to just use a virtual environment, either libkvm, or virtualbox, or vagrant, ... I recently needed a 'backport' of a current package for Ubuntu 12.04 LTS and set up vagrant in no time for it.

Edit: Here are my recent notes from when I needed a 64-bit Ubuntu 12.04 environment to (reb-)build / backport a current package in order to use it from Travis CI / GitHub. My host machine for this exercise was my 32-bit Ubuntu laptop which at the time ran Ubuntu 13.10:

  1. Install vagrant 1.5.1 deb from Vagrant
  2. Run vagrant init hashicorp/precise64 to set up a 64-bit Ubuntu 12.04 instance (cf the guide at http://docs.vagrantup.com/v2/getting-started/ and http://docs.vagrantup.com/v2/getting-started/boxes.html)
  3. Run vagrant up which takes a moment
  4. Run vagrant ssh and we are now at the prompt.
  5. [outside] copy a triplet dsc/orig.tar.gz/changes.gz into ~/vagrant/tmp which is shared with the Vagrant instance
  6. [inside again] Run sudo apt-get update; sudo apt-get install dpkg-dev followed by dpkg-source -x *.dsc
  7. [outside: edit debian/changelog as needed]
  8. run sudo apt-get install ....build-depends listed.... to install the listed Build-Depenbds
  9. run dpkg-buildpackage -us -uc -rfakeroot to build the package.

I have since deployed that binary package I created in a number of Travis builds. So there: creating a 64-bit package on a 32-bit system.

Vagrant is one rather popular tool, and used by a large number of virtual providers.

If you are on 64-bit Linux as a host, you can do even better via docker.io which likely the lighest, fastest, and highest performing method (and hence likely to outperform the Qemu approach -- eg this recent post

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • pbuilder seems for building on the same platform of the target : there's no cross-compiling. Moreover it seems his problem is due by a compilation/configuration problem of the cross-binutils, so it his not linked to his package build system. – user2284570 Apr 30 '14 at 22:31
  • I am building Debian i386 binaries in a pb under chroot on my amd64 server, and have done so for several years. – Dirk Eddelbuettel Apr 30 '14 at 22:55
  • It's still not cross-compilation:unlike many 64-bits architectures *(like mips64)*, x86_64 can run IA-32 programs natively, the revert is not true:you need a wrapper for converting the instructions and system calls.Using pbuilder directly involve using a cross-compiler/linker which make many problems *(absent symlinks;hard-coded path in scripts;Makefiles without configure scripts;custom build environment untested for cross-compiling...)*. Same things for para-virtualisers:They don't emulate any processor :they wrap interrupts *(this include moderns hypervisors : Virtualbox;libkvm;vagrant...)*. – user2284570 May 01 '14 at 08:16
  • I am not sure I follow your your obsession is: the OP asked about how to create a package for arch A on arch B, I have done exactly that literally hundreds of times and stated that approach as a solution because it works. – Dirk Eddelbuettel May 01 '14 at 10:11
  • Does `pbuilder` have built-in support for compilation? She/He ask for creating 64 bits package on a 32 bits machine, not compiling 32 bits programs on on 64 bits architecture. Both case are "*create a package for arch A on arch B*", but in one case, the CPU can't run both of the architectures. I remember spending often weeks to get a simple library compiled, when I was using cross-compilation. – user2284570 May 01 '14 at 12:12
  • Please read the docs I link I provided. These days every Intel cpu can run either i386 or amd64 which is what allows you the chroot separation upon which pbuilder rests. – Dirk Eddelbuettel May 01 '14 at 12:17
  • Except if he use a 32-bits kernel with is 32-bits only rootfs. So, it may be not as simple as using a single chroot. – user2284570 May 01 '14 at 12:18
  • Maybe. I have uploaded hundreds of i386 binaries from a chroot on amd64. I have also built amd64 binaries in a virtual instance (vagrant) on a i386 host. I think you could chroot an amd64 on a i386 host as well; but even if that were to fail vagrant *will work*. So would you consider stopping your tirades now before they reach a dozen comments for a sole question? – Dirk Eddelbuettel May 01 '14 at 12:33
  • Ok, vagrant emulate hardware in a similar way as qemu-system *(the virtual machine way)*. So, same thing : *wait*... *wait*. The advantage is that it automate the installation process for the environment. I guess it should be faster for x86_64 than for mips32. – user2284570 May 04 '14 at 01:20
  • Irrelevant. He wants Intel 64bit binarties built on an Intel 32bit host. Nobody is asking about _emulation of different hardware_. Only you keep bringing it up, repeatedly. – Dirk Eddelbuettel May 04 '14 at 01:22
  • Yes, and cross-compiling can solve the problem in that way *(which the OP fail to build)*. You are right vagrant seems to worked. – user2284570 Dec 15 '14 at 22:45
  • @DirkEddelbuettel, it would be nice if you would elaborate just a bit on the provider being used by vagrant to provide the amd64 guest environment on an i386 host system. AFAIK, virtualbox, vmware, and possibly docker were the only providers that were supported by vagrant around the 1.5.1 release. Were you using a qemu plugin, or similar? – umeboshi Dec 27 '14 at 03:26
  • Most likely virtualbox. – Dirk Eddelbuettel Dec 27 '14 at 03:36
0

You need to install the multiarch package to get the ability to have both amd64 and i386 tools and libs living on the same system. Of course, the amd64 tools and libs won't work if your host architecture is only i386, so I agree with @user2284570 about the qemu user emulation.

Brian Minton
  • 3,377
  • 3
  • 35
  • 41
  • 1
    No : `multiarch`is only available to compile and run 32-bits binaries inside a 64-bits rootfs. It is mainly for setting paths, so programs can find different resources and won't complain to use a bad architecture for specific shared object file. It can't help on a plain 32-bits rootfs. – user2284570 May 03 '14 at 10:22