|
Size: 9209
Comment:
|
Size: 9826
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| 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. | The FAQ below seems to be horribly out of date and still talks about the obsolete biarch that has been superceded 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. |
| Line 8: | Line 8: |
| The Debian on Amd64 FAQ | The Debian on amd64 FAQ |
| Line 20: | Line 20: |
| 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: Is this port only for AMD 64-bit ["CPUs"]? A: No. "amd64" is the name chosen by AMD for their 64-bit architecture. Before release, it was called "x86_64", and some distributions continue to use this name. Intel refers to its x86_64 instruction set ["CPUs"] as "["EM64T"]". The architecture is still the same, and Debian amd64 will run on AMD and Intel x86 processors with 64-bit support. In honor of the inventing company, AMD, Debian uses the name amd64. |
| Line 28: | Line 28: |
| 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/. | A: If you want stability, use the 32-bit version of Debian. A 64-bit distro is cooler and a bit faster, but not nearly as "smooth". If you want 64-bit, have a look at http://debian-amd64.alioth.debian.org/. |
| Line 36: | Line 36: |
| 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. |
Long answer: The problem is that 64-bit programs require 64-bit libraries, whereas 32-bit programs require 32-bit libraries, but there is only one standard place for the libraries (/lib, /usr/lib). pure64 is a clean port, and it uses only 64-bit libraries. pure64 does not run 32-bit 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 other 64-bit architectures such as ["SPARC64"]: libraries are split into /lib and /usr/lib for 32-bit libraries and /lib64 and /usr/lib64 for 64-bit libraries. This method is also used by RedHat and ["SuSE"] for their amd64 version, because you can still install and run old 32-bit programs. However, conceptually it is a mess, because every library package has to be edited in order to compile a 64-bit version. gcc-3.4 is a port based on a new compiler version, which is now an experimental prerelease of gcc-4.0. This version is supposed to be faster and better suited for multiarch, but it may not be as stable. |
| Line 49: | Line 48: |
| 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: Ok, so how do I run OpenOffice? A: OpenOffice does not compile on a 64-bit system. There are two alternatives, a clean (and difficult) one and a simple, but slightly messy one. The clean solution is to install a 32-bit system in a chroot environment. There are many ways to do that, the HOWTO covers some of them. If you already have a 32-bit installation, you can (re-)use it for the chroot environment. You will also probably need to mount /proc and /tmp in the chroot environment. The second solution is to use the packages in http://debian-amd64.alioth.debian.org/openoffice.org/, which install the necessary 32-bit libraries and a 32-bit version of OpenOffice in /emul. Works for me (after adding a few more libraries). ---- Q: Does Wine work? A: No, it seems like Wine has problems on recent kernels (especially 2.6.10), and it also has issues with 64-bit kernels. In theory, it should work. But it did not work for me. |
| Line 65: | Line 64: |
| 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: it is a 32bit binary, so you need a 32bit system and a 32bit browser. 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. |
A: partimage does not appear to be written to work on a 64-bit system. You may be able to use a 32-bit binary. You can also resort to using dump*fs, xfsdump, ntfsclone, or similar programs. ---- Q: What about Flash? A: Same story: It's a 32-bit binary, so you need a 32-bit system and a 32-bit browser. Personally, I do not want to lose the performance gain of a 64-bit browser only to be able to play anoying ads, but there may be better reasons to have Flash working that justify the tradeoff. ---- Q: How do I install 64-bit modules using 32-bit userspace? A: Refer to: http://url.raw.no/?628 . It includes a patch for both the kernel and the modutils that you will need to apply. |
| Line 83: | Line 82: |
| A: Use the 32bit version, it works. All you need is the image memtest86.bin. | A: Use the 32-bit version, it works. All you need is the image memtest86.bin. |
| Line 91: | Line 90: |
| The following solution is based on the [https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274383 Debian-["AMD64"] Howto 'Running applications inside the chroot' Section]. Simplest way to build i386 packages out of the box on amd64 is to use dchroot and a simple wrapper script like the following example for dpkg-buildpackage: |
The following solution is based on the [https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274383 Debian-["AMD64"] Howto 'Running applications inside the chroot' Section]: {{{ Simplest way to build i386 packages out of the box on amd64 is to use dchroot and a simple wrapper script such as the following example for dpkg-buildpackage: }}} |
| Line 99: | Line 100: |
Save it under /usr/local/bin/ia32-dpkg-buildpackage, make it executable and change the chroot name according to your environment. You need to have your home directory available under the chroot. Now you can build i386 packages using ia32-dpkg-buildpackage like dpkg-buildpackage. for example: |
{{{ Save it under /usr/local/bin/ia32-dpkg-buildpackage, make it executable and change the chroot name according to your environment. }}} {{{ You will need to have your home directory available under the chroot. }}} {{{ Now you can build i386 packages using ia32-dpkg-buildpackage like dpkg-buildpackage. for example: }}} |
| Line 108: | Line 113: |
remind to install the build-depends for the package inside the chroot. |
{{{ Remember to install the build-depends for the package inside the chroot. }}} |
| Line 117: | Line 123: |
| 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. |
dpkg-libinfo was added by Gerhard Tonn. It was originally written for the s390x and sparc64 ports. It allows debian/rules files to figure out if /lib or /lib64 should be used. See --help, or the usage of dpkg-libinfo in the zlib source. dpkg-subarchitecture was added by Bart Trojanowski. The main goal of dpkg-subarchitecture is to allow for the concurrent installation of packages that were compiled for different CPU types, but can still 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 /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 the scripts, the dpkg architecture name was changed to 'amd64'. Thus the names of 64-bit packages are named *_amd64.deb. Apt's /etc/apt/sources.list has a new feature, too: You can specify what architecture apt should pull from a given distribution mirror. Below is an example that instructs apt to use the binary-i386 part of the testing distribution. If the "(i386)" is omitted, the default binary-amd64 would be used. |
| Line 128: | Line 134: |
| 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: | In addition, apt now uses the dpkg-subarchitecture script to determine whether 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 |
| Line 134: | Line 140: |
| 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. | There are a few other features that still need to be added to apt and dpkg. The next one that has been requested is a test for library ["ABIs"]. Basically, binaries of any architecture can depend on applications of any other architecture, but for binaries that depend on libraries, apt would have to make sure that the ABI of both packages is compatible. For example, an i386 and i686 package have compatible ABI, but amd64 and ia64 do not. Again, this information is captured in the subarchtable file previously mentioned. |
| Line 147: | Line 153: |
| If everything works out you will have a '''package-version_amd64.deb''' generated. | If everything works (i.e., there are no problems in the code that affect building it on a 64-bit system), you should have a '''package-version_amd64.deb'''. |
| Line 153: | Line 159: |
| A: With biarch, that used to be a pain, but with pure64 it should be no different from an ordinary package. | A: With biarch, that used to be a pain, but with pure64 building a library should be no different from building an ordinary package. |
| Line 159: | Line 165: |
| 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 |
A: With pure64, it is a simple as {{{ gcc hello.c. }}} gcc will automatically target a 64-bit system. You can add -m32 to get a 32-bit executable. ---- Q: Lots of us don't care about 32-bit compatibility -- we don't |
| Line 171: | Line 182: |
| 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="x86_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 |
Q: How do I bootstrap a 64-bit system? A: There are many ways. You can just download the installer and create a new 64-bit installation. You can also use debootstrap from a running system. Remember that you will need a 64-bit kernel for a 64-bit system. Using the 64-bit kernel for a 32-bit system may work, but there will probably be problems with loadable modules. You can also recompile the system from source 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="x86_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. |
The FAQ below seems to be horribly out of date and still talks about the obsolete biarch that has been superceded 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 64-bit ["CPUs"]?
A: No. "amd64" is the name chosen by AMD for their 64-bit architecture. Before release, it was called "x86_64", and some distributions continue to use this name. Intel refers to its x86_64 instruction set ["CPUs"] as "["EM64T"]". The architecture is still the same, and Debian amd64 will run on AMD and Intel x86 processors with 64-bit support. In honor of the inventing company, AMD, Debian uses the name amd64.
Q: What distribution should I use? pure64, biarch, gcc-3.4?
A: If you want stability, use the 32-bit version of Debian. A 64-bit distro is cooler and a bit faster, but not nearly as "smooth". If you want 64-bit, 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 64-bit programs require 64-bit libraries, whereas 32-bit programs require 32-bit libraries, but there is only one standard place for the libraries (/lib, /usr/lib).
pure64 is a clean port, and it uses only 64-bit libraries. pure64 does not run 32-bit 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 other 64-bit architectures such as ["SPARC64"]: libraries are split into /lib and /usr/lib for 32-bit libraries and /lib64 and /usr/lib64 for 64-bit libraries. This method is also used by RedHat and ["SuSE"] for their amd64 version, because you can still install and run old 32-bit programs. However, conceptually it is a mess, because every library package has to be edited in order to compile a 64-bit version.
gcc-3.4 is a port based on a new compiler version, which is now an experimental prerelease of gcc-4.0. This version 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 64-bit system. There are two alternatives, a clean (and difficult) one and a simple, but slightly messy one. The clean solution is to install a 32-bit system in a chroot environment. There are many ways to do that, the HOWTO covers some of them. If you already have a 32-bit installation, you can (re-)use it for the chroot environment. You will also probably need to mount /proc and /tmp in the chroot environment.
The second solution is to use the packages in http://debian-amd64.alioth.debian.org/openoffice.org/, which install the necessary 32-bit libraries and a 32-bit version of OpenOffice in /emul. Works for me (after adding a few more libraries).
Q: Does Wine work?
A: No, it seems like Wine has problems on recent kernels (especially 2.6.10), and it also has issues with 64-bit kernels. In theory, it should work. But it did not work for me.
Q: Where is partimage?
A: partimage does not appear to be written to work on a 64-bit system. You may be able to use a 32-bit binary. You can also resort to using dump*fs, xfsdump, ntfsclone, or similar programs.
Q: What about Flash?
A: Same story: It's a 32-bit binary, so you need a 32-bit system and a 32-bit browser. Personally, I do not want to lose the performance gain of a 64-bit browser only to be able to play anoying ads, but there may be better reasons to have Flash working that justify the tradeoff.
Q: How do I install 64-bit modules using 32-bit userspace?
A: Refer to: http://url.raw.no/?628 . It includes a patch for both the kernel and the modutils that you will need to apply.
Q: Where is memtest for ["AMD64"]?
A: Use the 32-bit 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 inside your i386 chroot. Package is linux32.
The following solution is based on the [https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274383 Debian-["AMD64"] Howto 'Running applications inside the chroot' Section]:
Simplest way to build i386 packages out of the box on amd64 is to use dchroot and a simple wrapper script such as the following example for dpkg-buildpackage:
#!/bin/sh rpath=`pwd` dchroot -c i386 "cd $rpath && linux32 dpkg-buildpackage -ai386 $@"
Save it under /usr/local/bin/ia32-dpkg-buildpackage, make it executable and change the chroot name according to your environment.
You will need to have your home directory available under the chroot.
Now you can build i386 packages using ia32-dpkg-buildpackage like dpkg-buildpackage. for example:
$ ia32-dpkg-buildpackage -rfakeroot
Remember to install the build-depends for the package inside the chroot.
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 was originally written for the s390x and sparc64 ports. It allows debian/rules files to figure out if /lib or /lib64 should be used. See --help, or the usage of dpkg-libinfo in the zlib source.
dpkg-subarchitecture was added by Bart Trojanowski. The main goal of dpkg-subarchitecture is to allow for the concurrent installation of packages that were compiled for different CPU types, but can still 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 /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 the scripts, the dpkg architecture name was changed to 'amd64'. Thus the names of 64-bit packages are named *_amd64.deb.
Apt's /etc/apt/sources.list has a new feature, too: You can specify what architecture apt should pull from a given distribution mirror. Below is an example that instructs apt to use the binary-i386 part of the testing distribution. If the "(i386)" is omitted, the default binary-amd64 would be used.
deb http://ftp.debian.org/debian/ testing(i386) main non-free contrib
In addition, apt now uses the dpkg-subarchitecture script to determine whether 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 still need to be added to apt and dpkg. The next one that has been requested is a test for library ["ABIs"]. Basically, binaries of any architecture can depend on applications of any other architecture, but for binaries that depend on libraries, apt would have to make sure that the ABI of both packages is compatible. For example, an i386 and i686 package have compatible ABI, but amd64 and ia64 do not. Again, this information is captured in the subarchtable file previously mentioned.
Q: How do I port a debian package to amd64?
A: There should be no porting necessary, so just use the standard commands:
apt-get source package cd package-version dpkg-buildpackage
If everything works (i.e., there are no problems in the code that affect building it on a 64-bit system), you should have a package-version_amd64.deb.
Q: Ok, so what do I have to do to port a library package to amd64?
A: With biarch, that used to be a pain, but with pure64 building a library should be no different from building 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 64-bit system. You can add -m32 to get a 32-bit 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 a 64-bit system?
A: There are many ways.
You can just download the installer and create a new 64-bit installation. You can also use debootstrap from a running system. Remember that you will need a 64-bit kernel for a 64-bit system. Using the 64-bit kernel for a 32-bit system may work, but there will probably be problems with loadable modules.
You can also recompile the system from source 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="x86_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.
