Differences between revisions 1 and 2
Revision 1 as of 2004-01-11 21:33:59
Size: 11333
Editor: anonymous
Comment:
Revision 2 as of 2004-01-12 02:24:49
Size: 12431
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 186: Line 186:
Q: How do I build my first amd64 binaries? Do I need to download bart's biarch gcc, or does debian main contain enough to cross compile?
Line 187: Line 188:
A: You can build your own toolchain, but that's likely more work and less helpful for the project.
Line 188: Line 190:
Q: How do I build my first amd64 binaries? Do I need to download bart's biarch gcc, or does debian main contain enough to cross compile? You will need the latest [http://debian-amd64.alioth.debian.org/pool/glibc/ glibc] and [http://debian-amd64.alioth.debian.org/pool/gcc-3.3/ gcc-3.3] packages from the alioth pool (my -- bart's -- packages may be stale as other people build and update the official alioth pool) to build an amd64 binary.

You will likely run something like this:{{{
    gcc -m64 -o foo foo.c
}}}
The -m64 is currently essential to build amd64 binaries. In the future we hope this to be the default, but currently 32bit binaries are the default.

You can also get a gcc-wrapper, such as [http://www.jukie.net/~bart/debian/amd64/scripts/gcc.bart gcc.bart] and install it as instructed in the script. This will automatically insert the -m64 flag if you are running a 64bit kernel.

Note that to run these binaries you will need to get a 64bit kernel. You can either install a 2.4 or 2.6 kernel. Some [http://debian-amd64.alioth.debian.org/pool/kernel-patch-2.4.23-amd64/ prebuilt kernels] are available on alioth.

The FAQ

   This page holds the frequently asked questions regarding the Debian port to ["AMD64"].

   If there are unanswered questions the best thing you can do is to add the Q's at the bottom of this page.


Q: How do I install 64bit modules using 32bit userspace?

A: Refer to: http://url.raw.no/?628 . It includes a patch for both the kernel and the modutils which you need to apply.


Q: memtest for ["AMD64"]?

A: A patched version of memtest can be found here... http://linuxwiki.org/["AMD64"]/MemTest86


Q: What are those lib64 packages, and how are we going to work with them?

A: Biarch libs (that is, normal i386 library packages and lib64<libname>.amd64.deb packages) are built by first compiling the library like we have always done, then again with -m64 to get 64 bit mode. If you are updating a library package to become biarch, make sure that libs built with -m64 are installed into $prefix/lib64, not $prefix/lib.


Q: How do I build i386 debs on amd64?

A: use the linux32 command to fake uname and limit memory size. Package is linux32.


Q: How do I rebuild gcc for native 64 bit compilation? The version in Alioth is too old.

A: short answer: Don't. If you still want to try, it seems like a mixture of applying the debdiff from the latest version in alioth and adding at least %{!m32:--64} to AMD_SPEC in src/gcc/config/i386/x86-64.h. This is needed if you want a native compiler, which you most likely don't want.

What you probably want is to download the debdiff, apply it, resolve any conflicts and build the package with the linux32 personality (see above).


Q: Is there a quick rundown on the changes you've made to apt/dpkg command-line syntax anywhere?

A: There are two new scripts that were added to dpkg.

dpkg-libinfo was added by Gerhard Tonn. It's intended use was in the s390x and sparc64 ports. It allows debian/rules files to figure out if /lib or /lib64 should be used. See --help, or usage of it in zlib.

dpkg-subarchitecture was added by Bart Trojanowski. The main goal of this is to allow for concurrent instalation of packages that were compiled for different CPU types, but can be executed on the local host. As you may already know, on amd64 hardware you can install and run software compiled for k8, k7, i686, i586, i486 and i386. That relationship is captured in the ls /usr/share/dpkg/subarchtable; or see http://www.jukie.net/~bart/debian/amd64/files/dpkg/subarchtable. Note that this feature can also be used to build i686 optimized modules.

Along with that the dpkg architecture was changed to 'amd64'. This means that package names built in 64bit are named *_amd64.deb, while 32bit binaries can be installed from the i386 distribution of Debian.

Apt's sources.list has a new feture too. You can specify what architecture apt should pull in from a given distribution mirror. Below is an example that would instruct apt to use the binary-i386 part of the testing distribution. If the (i386) is ommited then the default binary-amd64 would be used.

  deb http://ftp.debian.org/debian/ testing(i386) main non-free contrib

In addition apt now uses dpkg-subarchitecture script to determine if certain packages are subarchitectures of amd64. The -s flag requests a list of compatible architectures that can be installed. The actual call that apt makes is:

  $ dpkg-subarchitecture -s -aamd64
  i686 i586 i486 i386 all

There are a few other features that will still go into apt and dpkg. The next one that is requested is the test of library ABI. Basically binaries of any architecture and depend on applications of any other architecture, but for binaries that depend on libraries apt would have to make sure that the ABI is compatible. That is an i386 and i686 package has compatible ABI, but amd64 and ia64 do not. Again this is captured in the subarchtable file mentioned above.


Q: Latest biarch gcc builds i386 code by default, is that right?

A: The final goal is to patch gcc to build based on the output of uname -m. That is to say if you have a 64bit kernel it will build 64bit binaries, and if you run gcc through 'linux32' it will build 32bit binaries. (apt-cache search linux32)

However, currently the gcc compiler available will build 32bit binaries regardless of the environment. This is bad since we want to build 64bit binaries most of the time.

For now there is a wrapper script that fixes this. The script looks at 'uname -m' and determines if -m32 or -m64 should be used. Get it here: http://www.jukie.net/~bart/debian/amd64/scripts/gcc.bart


Q: How do I port a binary package to amd64?

A: There should be no porting involved in most non-library packages. Just make sure you have the build system (including subarch dpkg and apt, and the biarch toolchain and glibc). So you should be able to run:

  apt-get source package
  cd package-version
  dpkg-buildpackage

If everything works out you will have a package-version_amd64.deb generated.


Q: Ok, so what do I have to do to port a library package to amd64?

A: While porting a package to amd64 please keep in mind that the port aims at a biarch system -- that is we would like to give the users the ability, if they so chose, to run some software in 64bit and some software in 32bit. Since amd64 executes i386 we will not reinvent the wheel and just install i386 binaries for our 32bit software, and we only need to build new packages for amd64.

Libraries make biarch support difficult. In order to support 32bit and 64bit apps you need some libraries to exist as 32bit and 64bit variants (ex glibc -- all programs need it). A decision was made to install 32bit libs in /lib and 64bit libs in /lib64. And since i386 packages already put their binary files into /lib we only need to make sure that 64bit packages place their binary files into /lib64.

For the sake of example, let's say that you are porting a simple library called foo. Since this is a simple package, before amd64 came along the libfoo package only generated libfoo-<version>_i386.deb and libfoo-dev-<version>_i386.deb. I will use this package as an example in the text to follow to go through the steps of porting this library.

There are three things you have to change in the library; these are:

  • in debian/control add lib64foo and lib64foo-dev with architecture set to amd64 (this will likely be later changed to something like {lib64} or {64bit}, but currently you can use amd64 or a complete list of 64bit architectures); your addition will look like this (you could also use the .64 suffix for Package field, see below):

   Package: lib64foo
   Architecture: amd64 s390x sparc64
   Priority: optional
   Depends: ${shlibs:Depends}
   Description: ...

   Package: lib64foo-dev
   Architecture: amd64 s390x sparc64
   Priority: optional
   Depends: lib64foo (= ${Source-Version}), libfoo-dev (= ${Source-Version}), lib64c6-dev
   Description: ...
  • in debian/rules add code to generate lib64foo and lib64foo-dev so that binary files end up in /lib64; the subarch dpkg was based on Gerhard Thonn's lib64 package and hence includes dpkg-libinfo which you should use to make your life easier; your changes may look like this:

   libname=$(shell /usr/bin/dpkg-libinfo -["qDEB"]_LIBNAME)
   libdir=$(shell /usr/bin/dpkg-libinfo -["qDEB"]_LIBDIR)
   lib64_arch=$(shell /usr/bin/dpkg-libinfo -["qDEB"]_["LIB64"]_ARCH)

   ifeq ($(lib64_arch),1)
   pkg=lib64foo
   else
   pkg=libfoo
   endif

   ...

   build: build-stamp
   build-stamp:
       dh_testdir
       cd src && .''configure --libdir=\$${exec_prefix}''${libname}

   ...
  • use ${libname} and ${libdir} variables in debian/.dirs files to generate the correct paths for installation

In the first bullet, there is a mention of .64 suffix. Intead of adding new blocks into the control file you could instead modify the existing default libfoo and libfoo-dev block to look like this:

   Package: libfoo
   Package.64: lib64foo
   Architecture: any
   Priority: optional
   Depends: ${shlibs:Depends}
   Description: ...

   Package: libfoo-dev
   Package.64: lib64foo-dev
   Architecture: any
   Priority: optional
   Depends: ...
   Description: ...

Note however that this approach does not work for the lib64foo-dev package since this package needs to depend on it's 32bit counterpart, but you cannot at this time specify special dependencies for 64bit packages (work to fix this is under way). For now, you should add a new entry in the control file.

Anyway, once the changes are complete, running dpkg-buildpackage should result in lib64foo-<version>_amd64.deb and lib64foo-dev-<version>_amd64.deb, while running linux32 dpkg-buildpackage should build the same binaries as a build on a 32bit x86 machine.

In the end, this seems fairly simple. But I did use a simple example on purpose; for some packages this may be a lot different and a great deal more involved. Gotcha's may include things like:

  • non library files (text, shell scripts, etc) in libfoo*_i386.deb
    • Problem: if this text file or shell script exists in both libfoo and lib64foo then they cannot be installed concurrently
    • Solution: you can do one of two things
      1. Ideally you would want to remove the conflict by creating a new package for the text file or shell script; call it something like libfoo-common (or libfoo-data).
      2. Alternatively you can start by making only libfoo contain the shell script or text file and make lib64foo depend on libfoo.
  • header files for -dev packages
    • Problem: a common library -dev package contains a /usr/lib/foo.a library, and header files . The foo.a file is not a problem, since the 64bit variant will end up in /usr/lib64. However, if both lib64foo-dev and libfoo-dev contain the header files then, as before, they cannot be installed concurrently. Also it is sometimes neccessary to vary the header files depending on the architecture.
    • Solution: the solution is again similar to the one above:
      1. Ideally, and given that your header files don't vary greatly with architecture, you can split the -dev package into libfoo-headers, libfoo-dev, and lib64foo-dev. The first package contains only the headers, while the two -dev packages depend on the headers package and contain just the foo.a files for their specific architecture.
      2. Alternatively you can make lib64foo-dev depend on lib64foo and make sure that the headers are only part of the 32bit package. This would mean that if someone wanted to do exclusively 64bit development with their library they would have to install the 32bit counterpart (which is not a big deal).
  • (and possibly more)

A good real-life example is zlib. Check out the debdiff that is available on alioth.

Finally, because you are a responsible poreter, you will check to make sure that you can:

  • build 32bit and 64bit packages,
  • install any package independently and concurrently (baring understood imposibilibites),
  • build against the 32bit and 64bit libraries.


Q: How do I build my first amd64 binaries? Do I need to download bart's biarch gcc, or does debian main contain enough to cross compile?

A: You can build your own toolchain, but that's likely more work and less helpful for the project.

You will need the latest [http://debian-amd64.alioth.debian.org/pool/glibc/ glibc] and [http://debian-amd64.alioth.debian.org/pool/gcc-3.3/ gcc-3.3] packages from the alioth pool (my -- bart's -- packages may be stale as other people build and update the official alioth pool) to build an amd64 binary.

You will likely run something like this:

    gcc -m64 -o foo foo.c

The -m64 is currently essential to build amd64 binaries. In the future we hope this to be the default, but currently 32bit binaries are the default.

You can also get a gcc-wrapper, such as [http://www.jukie.net/~bart/debian/amd64/scripts/gcc.bart gcc.bart] and install it as instructed in the script. This will automatically insert the -m64 flag if you are running a 64bit kernel.

Note that to run these binaries you will need to get a 64bit kernel. You can either install a 2.4 or 2.6 kernel. Some [http://debian-amd64.alioth.debian.org/pool/kernel-patch-2.4.23-amd64/ prebuilt kernels] are available on alioth.