|
Size: 14841
Comment:
|
Size: 8419
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| ---- ---- |
Well, I think we should give it a new start. So I have tried to find the relevant Q&As, and deleted the rest: |
| Line 9: | Line 8: |
| The FAQ | The Debian on Amd64 FAQ |
| Line 18: | Line 17: |
| Q: What distribution should I use? | |
| Line 20: | Line 18: |
| A: Use 32bit woody or sarge for your base system, the risk of accidentially hosing your system will be smaller that way. | Q: Is this port only for AMD-["CPUs"]? |
| Line 22: | Line 20: |
| Note: woody is better, this way the more uptodate and bi-arch debs will come from alioth, otherwise you may get the more recent i386 sarge debs instead. | A: No. "amd64" is the name chosen by AMD for the 64 bit architecture. Of course Intel does not want to use this name, so they call it x86_64 or ["EMT64"]. The architecture is still the same, and Debian amd64 will run on AMD and Intel x86 processors with 64bit support. In honor of the inventor AMD, Debian uses the name amd64. |
| Line 25: | Line 23: |
Q: What distribution should I use? pure64, biarch, gcc-3.4? A: If you want stability, use the 32bit version of Debian. A 64bit is cooler and a bit faster, but not nearly as "smooth". If you want 64bit, have a look at http://debian-amd64.alioth.debian.org/. ---- Q: Ok, so there is pure64, biarch, gcc-3.4 and more. Which one is the right one? A: Short answer: use pure64. Long answer: The problem is that 64bit programs require 64bit libraries, while 32bit programs require 32bit libraries, but there is only one standard place for the libraries. pure64 is a clean port, and it uses only 64bit libraries. pure64 does not run 32bit programs (in general), so there will be no Flash and no Openoffice. See below for workarounds. biarch is an old port, that followed the layout of the other 64bit architectures like ["SPARC64"]: libraries are split into /lib (for 32bit) and /lib64. This is also used by RedHat and Suse for their amd64 version, because you can still install and run old 32bit programs. However, conceptually it is a mess, because every library package has to be edited in order to compile a 64bit version. gcc-3.4 is a port based on a new compiler version, which is now an experimental prerelease of gcc-4.0. This is supposed to be faster and better suited for multiarch, but it may not be as stable. You should not mix these distributions. ---- Q: Ok, so how do I run openoffice? A: Openoffice does not compile on a 64bit system. There are two alternatives, a clean (and difficult) one and a simple, but slightly messy one. The clean one is to install a 32bit system in a chroot environment. There are many ways to do that, the HOWTO covers some of them. If you already have a 32bit installation, you can (re-)use it for the chroot environment. You probably need to mount /proc and /tmp in the chroot environment. You can also use the packages in http://debian-amd64.alioth.debian.org/openoffice.org/. They install the necessary 32bit libraries and a 32bit version of openoffice in /emul. Works for me (after adding a few more libraries). ---- Q: Wine does not work? A: Yes, it seems that wine has problems on recent kernels (especially 2.6.10), and it also has issues with 64bit kernels. In theory, it should work. But it did not for me. ---- Q: Where is partimage? A: Seems like partimage is not written to work on 64bit system. You may be able to use a 32bit binary. You can also resort of dump*fs, xfsdump, ntfsclone etc. ---- Q: And flash? A: Same story, but you also need a 32bit browser to use 32bit plugins. Personally, I do not want to loose the performance gain of a 64bit browser only to be able to play anoying ads, but there may be better reasons for flash. ---- |
|
| Line 30: | Line 78: |
| Q: memtest for ["AMD64"]? | |
| Line 32: | Line 79: |
| A: A patched version of memtest can be found here... http://linuxwiki.org/["AMD64"]/MemTest86 | Q: Where is memtest for ["AMD64"]? A: Use the 32bit version, it works. All you need is the image memtest86.bin. |
| Line 35: | Line 84: |
| Q: What are those lib64 packages, and how are we going to work with them? | |
| Line 37: | Line 85: |
| 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. ---- |
|
| Line 45: | Line 90: |
| Q: How do I rebuild gcc for native 64 bit compilation? The version in Alioth is too old. | |
| Line 47: | Line 91: |
| 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). ---- |
|
| Line 76: | Line 115: |
| 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 ---- |
|
| Line 99: | Line 129: |
| 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). 1. 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. 1. 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. |
A: The biarch, that used to be a pain, but with pure64 it should be no different from an ordinary package. |
| Line 200: | Line 132: |
| 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? | Q: How do I build my first amd64 binaries? |
| Line 202: | Line 134: |
| 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. |
A: With pure64, it is a simple as gcc hello.c. gcc will automatically target a 64bit system. You can add -m32 to get a 32bit executable. |
| Line 216: | Line 137: |
| Line 218: | Line 140: |
| Shouldn't that be simple to put together? Could it use the existing packages, or would we need to build up a separate set of packages? It seems as if that should be unambitious enough to get into the current release, even if the biarch stuff isn't ready yet. |
Shouldn't that be simple to put together? |
| Line 224: | Line 142: |
| A: Yes that's probably trivially possible. However, it will be very messy if you mix .debs from such a system and a biarch system. Also, I (tfheen) has heard some rumours that ftpmaster rejected such a port, so if those rumours are true, we don't want to waste our time on that. | A: Yes, and that is what pure64 gives you. |
| Line 227: | Line 145: |
| Q: I know that Suse et al. are using bin/ and bin64/, but that strikes me as backward-looking. I'd rather see amd64 libraries in /lib, and a separate chroot tree (i.e. ''ia32''{lib,usr/lib}, etc.) that gets substituted when loading a 32-bit binary. That is the approach on Itanium port (ia64). Is it Too Late to consider? |
|
| Line 232: | Line 146: |
| A: You would need to change where the kernel looks for the dynamic loader, and thus render yourself incompatible with other distributions, but apart from that, it's probably possible. However, we want to do the biarch port and avoid dirty hacks. ---- |
|
| Line 237: | Line 148: |
| A: following the debian-amd64-howto, I have found the following differences: | A: There are many ways. You can just download the installer and created a new 64bit installation. You can also use debootstrap from a running system. Remember that you need a 64bit kernel for a 64bit system. Using the 64bit kernel for a 32bit system may work, but there will probably be problems with loadable modules. Or you can recompile the system yourself: following the debian-amd64-howto, I have found the following differences: |
The FAQ below seems to be horribly out of date and still talks about the obsolete biarch that has been superseeded by a much cleaner [http://somewhere/ multiarch proposal]. I gave up reading halfway down the list without finding any reusable Q&A and gave up on it.
Please refer to the [https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html wiki:?HowTo Debian amd64] for a more up-to-date manual.
Well, I think we should give it a new start. So I have tried to find the relevant Q&As, and deleted the rest:
The Debian on Amd64 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: Is this port only for AMD-["CPUs"]?
A: No. "amd64" is the name chosen by AMD for the 64 bit architecture. Of course Intel does not want to use this name, so they call it x86_64 or ["EMT64"]. The architecture is still the same, and Debian amd64 will run on AMD and Intel x86 processors with 64bit support. In honor of the inventor AMD, Debian uses the name amd64.
Q: What distribution should I use? pure64, biarch, gcc-3.4?
A: If you want stability, use the 32bit version of Debian. A 64bit is cooler and a bit faster, but not nearly as "smooth". If you want 64bit, have a look at http://debian-amd64.alioth.debian.org/.
Q: Ok, so there is pure64, biarch, gcc-3.4 and more. Which one is the right one?
A: Short answer: use pure64.
Long answer: The problem is that 64bit programs require 64bit libraries, while 32bit programs require 32bit libraries, but there is only one standard place for the libraries.
pure64 is a clean port, and it uses only 64bit libraries. pure64 does not run 32bit programs (in general), so there will be no Flash and no Openoffice. See below for workarounds.
biarch is an old port, that followed the layout of the other 64bit architectures like ["SPARC64"]: libraries are split into /lib (for 32bit) and /lib64. This is also used by RedHat and Suse for their amd64 version, because you can still install and run old 32bit programs. However, conceptually it is a mess, because every library package has to be edited in order to compile a 64bit version.
gcc-3.4 is a port based on a new compiler version, which is now an experimental prerelease of gcc-4.0. This is supposed to be faster and better suited for multiarch, but it may not be as stable.
You should not mix these distributions.
Q: Ok, so how do I run openoffice?
A: Openoffice does not compile on a 64bit system. There are two alternatives, a clean (and difficult) one and a simple, but slightly messy one. The clean one is to install a 32bit system in a chroot environment. There are many ways to do that, the HOWTO covers some of them. If you already have a 32bit installation, you can (re-)use it for the chroot environment. You probably need to mount /proc and /tmp in the chroot environment.
You can also use the packages in http://debian-amd64.alioth.debian.org/openoffice.org/. They install the necessary 32bit libraries and a 32bit version of openoffice in /emul. Works for me (after adding a few more libraries).
Q: Wine does not work?
A: Yes, it seems that wine has problems on recent kernels (especially 2.6.10), and it also has issues with 64bit kernels. In theory, it should work. But it did not for me.
Q: Where is partimage?
A: Seems like partimage is not written to work on 64bit system. You may be able to use a 32bit binary. You can also resort of dump*fs, xfsdump, ntfsclone etc.
Q: And flash?
A: Same story, but you also need a 32bit browser to use 32bit plugins. Personally, I do not want to loose the performance gain of a 64bit browser only to be able to play anoying ads, but there may be better reasons for flash.
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: Where is memtest for ["AMD64"]?
A: Use the 32bit version, it works. All you need is the image memtest86.bin.
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: 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 feature 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: 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: The biarch, that used to be a pain, but with pure64 it should be no different from an ordinary package.
Q: How do I build my first amd64 binaries?
A: With pure64, it is a simple as gcc hello.c. gcc will automatically target a 64bit system. You can add -m32 to get a 32bit executable.
Q: Lots of us don't care about 32-bit compatibility, we don't run anything proprietary. We just want a native 64-bit port. Shouldn't that be simple to put together?
A: Yes, and that is what pure64 gives you.
Q: How do I bootstrap myself in 64 bits:
A: There are many ways. You can just download the installer and created a new 64bit installation. You can also use debootstrap from a running system. Remember that you need a 64bit kernel for a 64bit system. Using the 64bit kernel for a 32bit system may work, but there will probably be problems with loadable modules.
Or you can recompile the system yourself:
following the debian-amd64-howto, I have found the following differences: when compiling the kernel I had to 1) remove the ARCH:= line from the makefile and 2) use the command ARCH="x84_64" make HOSTCC="gcc -m32" CC="gcc -m64" LD="ld -m elf_x86_64" bzImage
Note: when using an MSI SCSI board, compile the kernel with SCSI and SCSI_DEV and MPT FUSION