Re: Debian for x86-64 (AMD Opteron) and migration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 16 June 2003 09:12, Emile van Bergen wrote: > # echo x86-64 >>/etc/dpkg/legal-archs > > or, if ordering matters, > > # echo x86-64 >/etc/dpkg/legal-archs.new > # cat /etc/dpkg/legal-archs >>/etc/dpkg/legal-archs.new > # mv /etc/dpkg/legal-archs.new /etc/dpkg/legal-archs AFAICS, ordering should not matter for dpkg, it will simply install any legal package when asked to. I have currently hardcoded the check for i386 packages into my amd64 dpkg... > The biggest objection that was raised is that it will be necessary > to make the source package for libreadline4 generate two packages, > libreadline4 and lib64readline4. Same for all other libraries. IOW, > there's no automatic way to create all these lib64* packages from > source. Currently, we are using a set of patches from Gerhard Tonn to build libraries on amd64 and on s390x that minimize the necessary source changes. Unfortunately, there has been no word about it from any dpkg or debhelper maintainer. See Bug #197117 and http://people.debian.org/~gt/lib64/. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+7eql5t5GS2LDRf4RAkwZAKCPAzwoeCHpDdBTFlZKlKvExqy3gwCbBzzW qS7btl9/G/tJeH7sNmVmaJg= =PV0Q -END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron) and migration?
Hi, On Mon, Jun 16, 2003 at 07:33:35AM +0200, Xavier Roche wrote: > Then, a nice thing would be on Debian, for a regular user/administrator: > > - switch the disks to a Opteron box > - update the APT sources to a "Opteron" source, or to a "Opteron > migration" source > - then, use something like : > apt-get install base-64 > to install the essential system files for 64-bit > apt-get install libc6-64 .. > essential libraries and elements for 64-bit code > apt-get kernel-image..-64 > 64-bit kernel for Opteron > > I'm not sure that all remarks are wise, but I did not see this > (migration) point clearly emerging from the "Debian for x86-64 (AMD > Opteron)" previous discussion Well, to some extent is was mentioned in the subthread by Wichert about dpkg being changed to allow multiple architectures at the same time, so that it's a matter of # echo x86-64 >>/etc/dpkg/legal-archs or, if ordering matters, # echo x86-64 >/etc/dpkg/legal-archs.new # cat /etc/dpkg/legal-archs >>/etc/dpkg/legal-archs.new # mv /etc/dpkg/legal-archs.new /etc/dpkg/legal-archs and suddenly an # apt-get install fvwm2 will fetch pool/main/f/fvwm/fvwm_2.4.6-2_x86-64.deb from the archive, and pull in packages such as lib64c6, lib64readline4, lib64gtk1.2. In this example, only one version (32 or 64 bit) of an application such as fvwm can exist on the system (package name is the same, only architecture field is different), whereas both libreadline4 and lib64readline4 can exist (package name is different too, and one installs its files in /usr/lib, the other in /usr/lib64 as per the AMD64 ABI). Of course, this may be different for other programs, which do require the '64' in the package name because some other program explicitly depends on a 64 bit version. But in general, this will only be true for libraries because they go in the same address space. Interfaces between programs and other programs will hopefully mostly be 64-bit clean. The biggest objection that was raised is that it will be necessary to make the source package for libreadline4 generate two packages, libreadline4 and lib64readline4. Same for all other libraries. IOW, there's no automatic way to create all these lib64* packages from source. Have I summarised this correctly? Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgp7VIRUBBmvE.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron) and migration?
Ok, a bit late in this thread, but just a small remark on the future Opteron port : we have to take a *great* care of the migration process. The main difference betweek Intel-64 and AMD-64, if I am correct, is that administrators can unplug their ix86 disk from the server, and replug it on a opteron box, swicth the power button, and that's it. You'll get almost the same machine, and the you can start the upgrade process to 64-bit for all applications that needs them, and them finish the migration. This is a process that takes time (and for some servers that will take months or years) Therefore you can migrate smoothly machines from the 32-bit world to the 64-bit world witout having to do a painful migration from a 32-bit server to a full 64-bit one ; this is, IMHO, the greatest advantage of Opteron. Many people will not switch to Itanium for this reason: you have to break everything, including production application that sill are 32-bit. Then, a nice thing would be on Debian, for a regular user/administrator: - switch the disks to a Opteron box - update the APT sources to a "Opteron" source, or to a "Opteron migration" source - then, use something like : apt-get install base-64 to install the essential system files for 64-bit apt-get install libc6-64 .. essential libraries and elements for 64-bit code apt-get kernel-image..-64 64-bit kernel for Opteron I'm not sure that all remarks are wise, but I did not see this (migration) point clearly emerging from the "Debian for x86-64 (AMD Opteron)" previous discussion (My 2 euro cents remark)
Re: Debian for x86-64 (AMD Opteron)
At Sat, 26 Apr 2003 03:01:58 +0200, Arnd Bergmann wrote: > On Friday 25 April 2003 19:36, Josselin Mouette wrote: > > > You know this will probably require modifications in *thousands* of > > packages ? > > Yes, I fully understand the impact. I've done it for half the packages > in something similar to Red Hat 9 on s390x and we're in the currently > building a minimal sid with /lib64 on s390x. BTW, is it really _good direction_ for supporting x86-64 ? I think this is really important decision. We're standing at a serious turning point. This issue is related with other arches, and I concern the future binaries/libraries compatibility. In addition, should all debian developers know about it when he packages libraries ? Regards, -- gotom
Re: Debian for x86-64 (AMD Opteron)
On Fri, 2003-04-25 at 11:54, Arnd Bergmann wrote: > This matter has been decided years ago by other people. /lib64 is > in the ELF psABI, see > http://www.linuxbase.org/spec/refspecs/elf/x86_64-SysV-psABI.pdf, > and upstream packages (e.g. KDE) are using it already. I haven't read that whole document, but 5.2.1 seems to say "it should go in /lib/ld64.so.1, but Linux is busted." I guess 9.2 is clear about the location of the other libraries, in the lib64 directories. signature.asc Description: This is a digitally signed message part
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 25 April 2003 19:36, Josselin Mouette wrote: > You know this will probably require modifications in *thousands* of > packages ? Yes, I fully understand the impact. I've done it for half the packages in something similar to Red Hat 9 on s390x and we're in the currently building a minimal sid with /lib64 on s390x. Experience shows that around 50% of the packages don't need any changes and 30% need trivial changes, e.g. updating the libtool and autoconf files. Since almost all binary packages from i386 can be used on amd64 without much performance impact, it is no problem if less important packages don't get ported for a long time. > I'm afraid I'm missing the point here : our other 64-bits arches don't > use /lib64, and they aren't in bad shape. What incompatibilities would > it bring to use our plain, good old /lib for x86-64 as well ? - Third-party amd64 packages. All of them. - i386 drop-in compatibility (you'd need to use a chroot) - LSB certification The existing 64 bit architectures (alpha and ia64) don't have a native 32 bit ABI, although they are both capable of running i386 binaries in an emulation mode with a significant performance loss. AFAIK, /lib64 is standardized for at least amd64, s390x, sparc64 and ppc64. mips64 and hppa and should probably use it as well, but I'm not sure about those. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+qdqI5t5GS2LDRf4RAnl3AJoCdGJ3mTF+aA4zRffDm6e25kPrMACeIOuB HHGLD8W0HExMDfjWxsF5rqM= =/rpC -END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
Le ven 25/04/2003 à 17:54, Arnd Bergmann a écrit : > > I am assuming that dlopen calls need to be modified to look for > > /usr/lib64 rather than /usr/lib on 64-bit architectures running > > 64-bit applications. > > This matter has been decided years ago by other people. /lib64 is > in the ELF psABI, see > http://www.linuxbase.org/spec/refspecs/elf/x86_64-SysV-psABI.pdf, > and upstream packages (e.g. KDE) are using it already. > > There are no other options to putting the library files in /lib64. > The question that needs to be discussed here is how to get them > there in all the broken packages. You know this will probably require modifications in *thousands* of packages ? I'm afraid I'm missing the point here : our other 64-bits arches don't use /lib64, and they aren't in bad shape. What incompatibilities would it bring to use our plain, good old /lib for x86-64 as well ? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 25 April 2003 16:32, Junichi Uekawa wrote: > I find that this might be better, than using /lib64, for 64-bit > mode libraries, because we need to modify almost everything that > uses dlopen, right ? > > I am assuming that dlopen calls need to be modified to look for > /usr/lib64 rather than /usr/lib on 64-bit architectures running > 64-bit applications. This matter has been decided years ago by other people. /lib64 is in the ELF psABI, see http://www.linuxbase.org/spec/refspecs/elf/x86_64-SysV-psABI.pdf, and upstream packages (e.g. KDE) are using it already. There are no other options to putting the library files in /lib64. The question that needs to be discussed here is how to get them there in all the broken packages. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+qVpB5t5GS2LDRf4RAp8aAJoCeP4o+zCtCfCQ/AvbRpdVh9asJQCeLRva BsnKec/hkAv6mUhwdZxIe2Q= =1hgr -END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
> This won't work, because you can't mix 32 and 64 bits code or libraries. > > I think the appropriate solution is to make it a completely new arch, > with 32 bits compatibility libraries (at least glibc and xlibs) allowing > to run 32 bits proprietary software. I find that this might be better, than using /lib64, for 64-bit mode libraries, because we need to modify almost everything that uses dlopen, right ? I am assuming that dlopen calls need to be modified to look for /usr/lib64 rather than /usr/lib on 64-bit architectures running 64-bit applications. This sounds like a rather drastic change. regards, junichi
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 21 April 2003 19:52, José Luis Tallón wrote:
> IMVHO, there is an intermediate alternative: why not ...
> ... create a new x86-64 architecture
> ... tweak dpkg so that ${DEB_ARCH}=="x86-64" admits both i386 and x86-64
> binaries;
> Naturally, x86-64 ("native") would be preferred to i386 when available. If
> there is no x86-64 binary, use i386 instead; Sky is blue, life is good ...
Yes, that is exactly the plan, please read the whole thread on how
this can be done. Note that in the beginning, all the packages are still
built as i386 packages, so dpkg does not have to be changed before it
can be built as a native 64 bit package itself.
Arnd <><
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+pERo5t5GS2LDRf4RArRfAKCHaIlOihK6hsR51QloXdKn7C17WQCeNS5o
oSKaM+9MPEt6rC+owlpD/GU=
=iZYy
-END PGP SIGNATURE-
Fwd: Re: Debian for x86-64 (AMD Opteron)
( forgot to Reply to the list, sorry )
Date: Mon, 21 Apr 2003 20:58:20 +0200
To: Josselin Mouette <[EMAIL PROTECTED]>
From: José Luis Tallón <[EMAIL PROTECTED]>
Subject: Re: Debian for x86-64 (AMD Opteron)
At 20:23 21/04/2003 +0200, you wrote:
Le lun 21/04/2003 à 19:52, José Luis Tallón a écrit :
> IMVHO, there is an intermediate alternative: why not ...
> ... create a new x86-64 architecture
> ... tweak dpkg so that ${DEB_ARCH}=="x86-64" admits both i386 and x86-64
> binaries;
> Naturally, x86-64 ("native") would be preferred to i386 when
available. If
> there is no x86-64 binary, use i386 instead; Sky is blue, life is good ...
This won't work, because you can't mix 32 and 64 bits code or libraries.
I think the appropriate solution is to make it a completely new arch,
with 32 bits compatibility libraries (at least glibc and xlibs) allowing
to run 32 bits proprietary software.
Correct me if i'm wrong -- you can't run 64bits software with 32bit
libraries, but you can run 64bit and 32bit processes concurrently, right?
Then: package foo64 would require libfoo64 -- apt-get will do the hard work
If there is no foo64, select foo [foo32] instead, which will pull libfoo
[libfoo32] from the archive if needed.
[ sonames would need to be tweaked in the 64bit versions, and some
adjustments might be necessary in the format of 'control' files ]
My point was on easing/accelerating availability of an x86-64 "port" of
Debian.
I most probably am overlooking something, however if there'd be a "PPC64"
or something ( transition to 64bits will happen sometime for all 32bit
architectures, i guess ), we would have most work already done... wouldn't we?
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
Regards,
J.L.
Re: Debian for x86-64 (AMD Opteron)
Le lun 21/04/2003 à 19:52, José Luis Tallón a écrit :
> IMVHO, there is an intermediate alternative: why not ...
> ... create a new x86-64 architecture
> ... tweak dpkg so that ${DEB_ARCH}=="x86-64" admits both i386 and x86-64
> binaries;
> Naturally, x86-64 ("native") would be preferred to i386 when available. If
> there is no x86-64 binary, use i386 instead; Sky is blue, life is good ..
Re: Debian for x86-64 (AMD Opteron)
At 01:18 22/04/2003 +1000, you wrote:
On Mon, 21 Apr 2003 21:18, Thomas Petazzoni wrote:
> Why don't we consider the x86-64 as beeing a 64-bits-only architecture
Because we want to run Netscape, commercial games, Frauhofer MP3 en/decoders,
Oracle, and other binary-only i386 software.
If AMD had made a 64bit only CPU and devoted those extra transistors to cache
it would have improved performance for 64bit code. After paying the
performance penalty of a 32bit ISA it makes sense to take advantage of it.
IMVHO, there is an intermediate alternative: why not ...
... create a new x86-64 architecture
... tweak dpkg so that ${DEB_ARCH}=="x86-64" admits both i386 and x86-64
binaries;
Naturally, x86-64 ("native") would be preferred to i386 when available. If
there is no x86-64 binary, use i386 instead; Sky is blue, life is good ...
so,
- We will have native, optimized, packages for x86-64, thus benefiting
from the increased memory space addressing, extra integer size, Y2K38
compatibility ;) ...
- Since dpkg will allow installing binary packages from i386
- We can have an x86-64 Debian right now :D ( Opteron should be
released tomorrow, IIRC )
- Autobuilders will have much less load -- they need not build
everything *right now*
- We can have an smooth transition to 64 bits
Any comments, remarks, suggestions, etc. very much appreciated
Regards,
J.L.
Re: Debian for x86-64 (AMD Opteron)
On Mon, 21 Apr 2003 21:18, Thomas Petazzoni wrote: > Why don't we consider the x86-64 as beeing a 64-bits-only architecture Because we want to run Netscape, commercial games, Frauhofer MP3 en/decoders, Oracle, and other binary-only i386 software. If AMD had made a 64bit only CPU and devoted those extra transistors to cache it would have improved performance for 64bit code. After paying the performance penalty of a 32bit ISA it makes sense to take advantage of it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Debian for x86-64 (AMD Opteron)
Michael Banck <[EMAIL PROTECTED]> writes: >> Anything to do with the ability to mix-and-match 32 and 64-bit code in this >> processors? > > Yes. Is there a reason for mixing 32 and 64 bits ? Isn't it just a feature included in the processor because other proprietary operating systems (and all the software) cannot be changed fastly to 64 bits ? Why don't we consider the x86-64 as beeing a 64-bits-only architecture ? Cheers, Thomas -- PETAZZONI Thomas - [EMAIL PROTECTED] - UIN : 34937744 http://www.enix.org/~thomas/ KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7
Re: Debian for x86-64 (AMD Opteron)
* Michael Banck <[EMAIL PROTECTED]> [2003-04-09 23:08]: > I talked to an AMD guy a while back, and he said we could get access > to machines if he sign certain NDAs. He did not really say what kind > of access though. I sent e-mail to AMD about getting a dedicated box for Debian a day before this thread started. While they still have limited resources and cannot give us a machine, they can provide a limited number of developers remote access through the AMD Developer Center. In fact, two Debian developers are presumably working on a port already, but I wasn't told who they were. So, if you are serious about this port and have time, contact me privately. -- Martin Michlmayr
Re: Debian for x86-64 (AMD Opteron)
I demand that José Luis Tallón may or may not have written...
[snip]
> Sorry, i must me missing something obvious, but why would we need lib64foo
> ? Why not just define the new architecture x86-64 and have katie/buildd do
> the rest?
[snip]
> Anything to do with the ability to mix-and-match 32 and 64-bit code in this
> processors?
If this is fairly easy, would it be better to compile 64-bit code and
generate 32-bit wrappers?
This would ideally be automated via libtool: if the install path is $FOO/lib,
put the wrappers there and the libraries in $FOO/lib64, first ensuring that
it exists. Also, for debian/*.files, an implicit
sed -re '%^lib/[^/]*.so[^/]*$% { p; s%^lib/([^/]*.so[^/]*)$%lib64/\1%; }
%/lib/[^/]*.so[^/]*$% { p; s%/lib/([^/]*.so[^/]*)$%/lib64/\1%; }'
would help.
It could be that I'm missing something here, but ISTM that that would get
things up and running without any need to modify (m)any packages.
--
| Darren Salt | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking | Northumberland
| RISC OS | demon co uk | Toon Army
| http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)
4 food groups: fast, frozen, microwaved, and junk.
Re: Debian for x86-64 (AMD Opteron)
On Sat, 2003-04-12 at 02:02, Eduard Bloch wrote: > #include > * Drew Scott Daniels [Thu, Apr 10 2003, 02:11:36PM]: > > I don't quite understand all the concepts being discussed but the > > following web pages may be worth reading. > > http://master.debian.org/~brinkmd/arch-handling.txt > > The idea is great and I came to very similar concept looking for a > solution for various dynamic dependency problems. However I think that > too many methods are hardcoded in Debian's packagement system I am hoping build-common will help solve that.
Re: Debian for x86-64 (AMD Opteron)
On Sat, Apr 12, 2003 at 09:15:32PM +0200, José Luis Tallón wrote: > [ Disclaimer: just subscribed -- caught the thread already started ] http://lists.debian.org/debian-devel > Why not just define the new architecture x86-64 and have katie/buildd do > the rest? > > Anything to do with the ability to mix-and-match 32 and 64-bit code in this > processors? Yes. cheers, Michael
Re: Debian for x86-64 (AMD Opteron)
At 19:10 12/04/2003 +0200, you wrote:
On Saturday 12 April 2003 16:58, Marcelo E. Magallon wrote:
> >> Arnd Bergmann <[EMAIL PROTECTED]> writes:
> >>
> > Every architecture knows where its libraries are installed. One way
> > would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either
> > 'lib' or 'lib64' depending on the architecture. You have to do
> > something like this anyway because the file list and the configure
> > arguments are also different.
>
> I feel my leg being pulled :-)
>
> Again, with -v -v -v, what do you write in the Architecture field
> corresponding to the lib64foo package in the debian/control file?
Ok, now I see your point. What I wanted to do is put 'Architecture: any'
in the control file and use debian/substvars to define the actual
name of the binary package, e.g. 'Package: ${lib}foo'. I suppose there
is a good reason why using a generated package name does not work, so
we have to come up with something else.
Sorry for the confusion.
[ Disclaimer: just subscribed -- caught the thread already started ]
Sorry, i must me missing something obvious, but why would we need lib64foo ?
Why not just define the new architecture x86-64 and have katie/buildd do
the rest?
Users with Opteron/Athlon64 would have the additional bonus of a completely
optimized distro to run ( as good as or better than using a source-based
distribution such as Gentoo ), and it would be completely transparent for
developers...
Anything to do with the ability to mix-and-match 32 and 64-bit code in this
processors?
Arnd <><
Regards,
J.L.
Re: Debian for x86-64 (AMD Opteron)
On Saturday 12 April 2003 16:58, Marcelo E. Magallon wrote:
> >> Arnd Bergmann <[EMAIL PROTECTED]> writes:
> >>
> > Every architecture knows where its libraries are installed. One way
> > would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either
> > 'lib' or 'lib64' depending on the architecture. You have to do
> > something like this anyway because the file list and the configure
> > arguments are also different.
>
> I feel my leg being pulled :-)
>
> Again, with -v -v -v, what do you write in the Architecture field
> corresponding to the lib64foo package in the debian/control file?
Ok, now I see your point. What I wanted to do is put 'Architecture: any'
in the control file and use debian/substvars to define the actual
name of the binary package, e.g. 'Package: ${lib}foo'. I suppose there
is a good reason why using a generated package name does not work, so
we have to come up with something else.
Sorry for the confusion.
Arnd <><
Re: Debian for x86-64 (AMD Opteron)
>> Arnd Bergmann <[EMAIL PROTECTED]> writes: > Every architecture knows where its libraries are installed. One way > would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either > 'lib' or 'lib64' depending on the architecture. You have to do > something like this anyway because the file list and the configure > arguments are also different. I feel my leg being pulled :-) Again, with -v -v -v, what do you write in the Architecture field corresponding to the lib64foo package in the debian/control file? -- Marcelo | "Real children don't go hoppity-skip unless they are [EMAIL PROTECTED] | on drugs." | -- Susan, the ultimate sensible governess |(Terry Pratchett, Hogfather)
Re: Debian for x86-64 (AMD Opteron)
On Saturday 12 April 2003 15:42, Marcelo E. Magallon wrote: > How do you generate binary packages libfoo or lib64foo out of source > foo depending on the target architecture? Every architecture knows where its libraries are installed. One way would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either 'lib' or 'lib64' depending on the architecture. You have to do something like this anyway because the file list and the configure arguments are also different. Arnd <><
Re: Debian for x86-64 (AMD Opteron)
On Sat, Apr 12, 2003 at 03:38:45PM +0200, Wichert Akkerman wrote: > Previously Marcelo E. Magallon wrote: > > That doesn't scale terribly well, does it? Everytime a new 64 bit > > architecture is introduced, all the library packages have to be updated > > by hand (instead of just being recompiled). > > I don't see that. You don't? How do you generate binary packages libfoo or lib64foo out of source foo depending on the target architecture? -- Marcelo
Re: Debian for x86-64 (AMD Opteron)
Previously Marcelo E. Magallon wrote: > That doesn't scale terribly well, does it? Everytime a new 64 bit > architecture is introduced, all the library packages have to be updated > by hand (instead of just being recompiled). I don't see that. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: Debian for x86-64 (AMD Opteron)
>> Wichert Akkerman <[EMAIL PROTECTED]> writes: > * modify dpkg (already planned) to allow it to install packages from > different architectures on a system where it makes sense > * change the naming of the libraries, for example by adding '64' to > the 64bit version of a library > > That way you could do something like: > > # echo x86-64 >> /etc/dpkg/legal-archs > # dpkg -i libgtk2-2.0-1_i386.deb > # dpkg -i lib64gtk2-2.0-1_x8664.deb That doesn't scale terribly well, does it? Everytime a new 64 bit architecture is introduced, all the library packages have to be updated by hand (instead of just being recompiled). The Arch field needs to be expanded, too, e.g. a la Brinkmann. -- Marcelo | "One o'clock pee em! Hello, Insert Name Here!" [EMAIL PROTECTED] | -- The Dis-organizer |(Terry Pratchett, Jingo)
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 12 April 2003 13:00, Wichert Akkerman wrote:
> Previously Arnd Bergmann wrote:
> > Yes, but what I also want to avoid is having to change every single
> > instance of 'Depends: libfoo' to 'Depends: libfoo [! x86_64, sparc64,
> > s390x, ppc64, hppa64], lib64foo [x86_64, sparc64, s390x, ppc64, hppa64]'
> > and then changing them all again for mips64 ;-).
>
> Since Depends are automatically calcuated by dpkg-shlibdeps I don't see
> the problem here.
Some examples: gcc-3.2 depends on libgcc1, kdenetwork depends on
libkdenetwork2 (=${Source-Version}), lsb depends on libz1 and libgl1.
None of these can be done with dpkg-shlibdeps. But you are right: while
there may be these exceptions, the vast majority of dependencies is
no problem.
Arnd <><
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+mACM5t5GS2LDRf4RAvJMAJ4ySRaSxEdpwv721L618yHR+TzjlgCdHefe
Nslw71kdaPs2rhXefjB220c=
=CFMT
-END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
Previously Arnd Bergmann wrote: > Yes, but what I also want to avoid is having to change every single instance > of 'Depends: libfoo' to 'Depends: libfoo [! x86_64, sparc64, s390x, ppc64, > hppa64], lib64foo [x86_64, sparc64, s390x, ppc64, hppa64]' and then changing > them all again for mips64 ;-). Since Depends are automatically calcuated by dpkg-shlibdeps I don't see the problem here. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: Debian for x86-64 (AMD Opteron)
#include * Drew Scott Daniels [Thu, Apr 10 2003, 02:11:36PM]: > I don't quite understand all the concepts being discussed but the > following web pages may be worth reading. > http://master.debian.org/~brinkmd/arch-handling.txt The idea is great and I came to very similar concept looking for a solution for various dynamic dependency problems. However I think that too many methods are hardcoded in Debian's packagement system and in too many maintainer's heads, so it will be just not possible to implement it in a sane way without forking a new distro. http://wiki.debian.net/BrainStorming MfG, Eduard.
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 11 April 2003 23:17, Emile van Bergen wrote: > > What I have in mind is something along the lines of > > libfoo 'Provides: libfoo(32bit)' > > lib64foo 'Provides: libfoo(64bit)' > > bar 'Depends: libfoo($BITSIZE)' > > I don't know if it's possible to teach dpkg and the other tools about > > this. > > I really have lost all clue of what you think is missing from current > behaviour. > > - lib64foo /already/ provides lib64foo. > - bar (a binary 64 bit package) can /already/ depend on lib64foo (and > not libfoo). > > What's the problem? The problem is when dpkg-shlibdeps can not determine the correct dependencies on library packages (e.g. a versioned Depends) and the package maintainer added an explicit 'Depends: libfoo (>= 1.2.3)' to the control file. Unless the source package is changed , the 64 bit binary will end up with 'Depends: lib64foo, libfoo (>=1.2.3)' instead of the correct 'Depends: lib64foo (>=1.2.3)'. Luckily, these seem to be far less common than I first though, so it could still be possible to do them by hand. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lzaw5t5GS2LDRf4RAk+3AJ9Xm+Vl/K78zi6o4/nC0LpREVZnVwCgop7v uPSmQuNwdri9aam2uRxeJPQ= =wSKS -END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
Hi, On Fri, Apr 11, 2003 at 09:42:52PM +0200, Arnd Bergmann wrote: > On Friday 11 April 2003 15:49, Emile van Bergen wrote: > > > You do want to allow both 32-bit and 64-bit versions of libraries to be > > installed, for which you need different package names; you want to avoid > > adding fields to a package's "primary key", so that the dependency tree > > assmebly mechanisms can be left as they are. > > Yes, but what I also want to avoid is having to change every single instance > of 'Depends: libfoo' to 'Depends: libfoo [! x86_64, sparc64, s390x, ppc64, > hppa64], lib64foo [x86_64, sparc64, s390x, ppc64, hppa64]' and then changing > them all again for mips64 ;-). You don't need that. Depends: libfoo will just stay Depends: libfoo. No lib64foo will be pulled in, as it has a DIFFERENT PACKAGE NAME. > What I have in mind is something along the lines of > libfoo 'Provides: libfoo(32bit)' > lib64foo 'Provides: libfoo(64bit)' > bar 'Depends: libfoo($BITSIZE)' > I don't know if it's possible to teach dpkg and the other tools about this. I really have lost all clue of what you think is missing from current behaviour. - lib64foo /already/ provides lib64foo. - bar (a binary 64 bit package) can /already/ depend on lib64foo (and not libfoo). What's the problem? Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpbq1ynPSDxN.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 11 April 2003 15:49, Emile van Bergen wrote: > On Thu, Apr 10, 2003 at 06:23:12PM +0200, Arnd Bergmann wrote: > > On Thursday 10 April 2003 16:43, Emile van Bergen wrote: > > > On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote: > > > > # echo x86-64 >> /etc/dpkg/legal-archs > > > > # dpkg -i libgtk2-2.0-1_i386.deb > > > > # dpkg -i lib64gtk2-2.0-1_x8664.deb > > I'm not sure how to best handle dependencies on this. > > Simple: explicitly. I don't think it'd be a good idea to allow 32-bit > apps to link to 64-bit libraries and vice versa. How would you layout > the (shared) address space? Handling all cases would become a mess > quickly. Right. In case it was not clear to everybody: The ELF format does not specify linking of 32 and 64 objects together, so this is not subject to discussion anyway. > You do want to allow both 32-bit and 64-bit versions of libraries to be > installed, for which you need different package names; you want to avoid > adding fields to a package's "primary key", so that the dependency tree > assmebly mechanisms can be left as they are. Yes, but what I also want to avoid is having to change every single instance of 'Depends: libfoo' to 'Depends: libfoo [! x86_64, sparc64, s390x, ppc64, hppa64], lib64foo [x86_64, sparc64, s390x, ppc64, hppa64]' and then changing them all again for mips64 ;-). What I have in mind is something along the lines of libfoo 'Provides: libfoo(32bit)' lib64foo 'Provides: libfoo(64bit)' bar 'Depends: libfoo($BITSIZE)' I don't know if it's possible to teach dpkg and the other tools about this. And this is only the tip of the iceberg: As Cyrille noted already, the real challenge will be finding a policy for the -dev packages. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lxq+5t5GS2LDRf4RAmHzAKCiqYgXZffN3cqtgF95aFd+rBVLHACfUjOH tje7TlhqQD5ySvSs6bNJwr0= =hmhD -END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
Hi,
On Thu, Apr 10, 2003 at 06:23:12PM +0200, Arnd Bergmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thursday 10 April 2003 16:43, Emile van Bergen wrote:
>
> > On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:
>
> > >
> > > # echo x86-64 >> /etc/dpkg/legal-archs
> > > # dpkg -i libgtk2-2.0-1_i386.deb
> > > # dpkg -i lib64gtk2-2.0-1_x8664.deb
> >
> > libssl0.9.6-0.9.6c-2_i386.deb or
> > libssl0.9.6-0.9.6c-2_i686.deb;
> >
> > on a x86-64 you'd have the choice between those same two plus
> >
> > libssl0.9.6-0.9.6c-2_x8664.deb
>
> These two proposals have a significant difference. The first one
> needs more changes to the individual library packages because it
> changes not only the file names but also the package names. I'm
> not sure how to best handle dependencies on this.
Simple: explicitly. I don't think it'd be a good idea to allow 32-bit
apps to link to 64-bit libraries and vice versa. How would you layout
the (shared) address space? Handling all cases would become a mess
quickly.
You do want to allow both 32-bit and 64-bit versions of libraries to be
installed, for which you need different package names; you want to avoid
adding fields to a package's "primary key", so that the dependency tree
assmebly mechanisms can be left as they are.
> The second proposal would mean that dpkg will have to be changed
> so it can install the same package for both x8664 and {i386,i686}
> at the same time, which could prove difficult. The dependencies
> here can basically stay the same (e.g. ssh will continue to
> depend on libssl0.9.6 even on 64 bit), but dpkg and apt will have
> to know about an additional dimension concerning dependencies, e.g.:
That is exactly what Wichert wanted to avoid. I'm sorry, you probably
got this idea because of a most unfortunate typo of mine in the last
.deb I mentioned; I meant lib64ssl0.9.6-0.9.6c-2_x8664.deb there.
There are two distinct issues I wanted to illustrate:
1. different package name (for 64 bits), different architecture,
more than one architecture allowed by dkpg: allows 32-bit and 64-bit
versions of packages to coexist; allows (64-bit) machines to install
packages from compatible (32-bit) architectures. This was Wichert's
idea.
2. same package name, different "architecture", more than one
architecture allowed by dpkg: solves CPU optimized libraries in
a transparent way; no changes to dependencies necessary. This is what
Wichert's suggested extension to dpkg would allow when using the same
package name.
Hope it's clear now.
Cheers,
Emile.
--
E-Advies - Emile van Bergen [EMAIL PROTECTED]
tel. +31 (0)70 3906153 http://www.e-advies.nl
pgpEKvXwn6hs9.pgp
Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
* Daniel Jacobowitz <[EMAIL PROTECTED]> [030410 22:52]: > > What's wrong with /lib/ for 64 bits libs and /lib/32/ for the 32 bit > > legacy stuff (note the slash). > > > > Ofcourse, they'll get the rpath thing wrong and commercial applications > > are going to insist on /lib64, shiver. > > Well, it's written into the ABI documentation for at least a few > platforms now, so it's a bit late to do anything about it :( I think however it is implemented, it will open a whole can of worms. Also note the mess the move of sparc64 from */lib/64 to */lib64 caused to woddy. (one needs a "dpkg -r libc6-sparc64 libgcc1 libstdc++3 gcc-3.0 fakeroot && apt-get -u upgrade && apt-get install fakeroot" and perhaps some additional "dpkg --configure -a" if one missed something in between to upgrade to a new glibc. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 07:59:51PM +, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > Arnd Bergmann <[EMAIL PROTECTED]> wrote: > >Possible -- sure, but not useful except as an option for the initial > >bootstrap that might not fully work with /lib64. > >I've followed both SuSE and Red Hat making that mistake with their early > >s390x distributions. They both now have the problem that they changed > >to /lib64 installations, which makes it really hard to create 64 bit > >packages that work in the old _and_ new distributions. > > /lib64 ?! We're arguing for a month if adding a new top-level > directory called /run is a good idea and they just add a very > very ugly /lib64 ? > > What's wrong with /lib/ for 64 bits libs and /lib/32/ for the 32 bit > legacy stuff (note the slash). > > Ofcourse, they'll get the rpath thing wrong and commercial applications > are going to insist on /lib64, shiver. Well, it's written into the ABI documentation for at least a few platforms now, so it's a bit late to do anything about it :( -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Debian for x86-64 (AMD Opteron)
In article <[EMAIL PROTECTED]>, Arnd Bergmann <[EMAIL PROTECTED]> wrote: >Possible -- sure, but not useful except as an option for the initial >bootstrap that might not fully work with /lib64. >I've followed both SuSE and Red Hat making that mistake with their early >s390x distributions. They both now have the problem that they changed >to /lib64 installations, which makes it really hard to create 64 bit >packages that work in the old _and_ new distributions. /lib64 ?! We're arguing for a month if adding a new top-level directory called /run is a good idea and they just add a very very ugly /lib64 ? What's wrong with /lib/ for 64 bits libs and /lib/32/ for the 32 bit legacy stuff (note the slash). Ofcourse, they'll get the rpath thing wrong and commercial applications are going to insist on /lib64, shiver. Mike.
Re: Debian for x86-64 (AMD Opteron)
I don't quite understand all the concepts being discussed but the following web pages may be worth reading. http://master.debian.org/~brinkmd/arch-handling.txt http://lists.debian.org/debian-win32/2003/debian-win32-200302/msg00018.html http://lists.debian.org/debian-bsd/2002/debian-bsd-200202/msg00131.html Drew Daniels
Re: Debian for x86-64 (AMD Opteron)
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > multiple names. We could make this easier in dpkg probably. And then > you would only install i386 packages if there wasn't an x86-64 package > with the same package name... For application that approach (use x86-64 if available, i386 otherwise) would likely work. But for library packages it must be possible to install 32bit and 64bit versions in parallel, so it must be possible to separate glibc 32bit + glibc 64bit somehow. Using different names for 32bit and 64bit shared library packages is IMHO not a bad idea to deal with the issue. Sure, you have to touch every f*cking library package to implement that, but you have to do that anyway to move the 64bit versions of the shared libraries to /lib64 (and this in turn is needed to be compatible with the rest of the world). Gerd -- Gerd Knorr <[EMAIL PROTECTED]>
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 06:05:38PM +0200, Cyrille Chepelov wrote: > Le Thu, Apr 10, 2003, à 03:33:39PM +0200, Wichert Akkerman a écrit: > > > That way you could do something like: > > > > # echo x86-64 >> /etc/dpkg/legal-archs > > # dpkg -i libgtk2-2.0-1_i386.deb > > # dpkg -i lib64gtk2-2.0-1_x8664.deb > > Will we have to also have lib64gtk2.0-dev? Wouldn't that have pretty bad > inconvenient consequences on the build dependencies? I'm not sure this is really a good approach. Some concerns: - the names of all library packages would change on a 64-bit architecture; this is a hassle for library packagers - Would you have libgtk2-dev_2.0-1_x8664.deb or lib64gtk2_2.0-1_x8664.deb? Hmm... thinking about it some more, basically every package you wanted to treat this way would have to support building a package with multiple names. We could make this easier in dpkg probably. And then you would only install i386 packages if there wasn't an x86-64 package with the same package name... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 10 April 2003 16:43, Emile van Bergen wrote:
> On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:
> >
> > # echo x86-64 >> /etc/dpkg/legal-archs
> > # dpkg -i libgtk2-2.0-1_i386.deb
> > # dpkg -i lib64gtk2-2.0-1_x8664.deb
>
> libssl0.9.6-0.9.6c-2_i386.deb or
> libssl0.9.6-0.9.6c-2_i686.deb;
>
> on a x86-64 you'd have the choice between those same two plus
>
> libssl0.9.6-0.9.6c-2_x8664.deb
These two proposals have a significant difference. The first one
needs more changes to the individual library packages because it
changes not only the file names but also the package names. I'm
not sure how to best handle dependencies on this.
The second proposal would mean that dpkg will have to be changed
so it can install the same package for both x8664 and {i386,i686}
at the same time, which could prove difficult. The dependencies
here can basically stay the same (e.g. ssh will continue to
depend on libssl0.9.6 even on 64 bit), but dpkg and apt will have
to know about an additional dimension concerning dependencies, e.g.:
ssh (64 bit) depends on libssl0.9.6 (64 bit)
ssh (32 bit) depends on libssl0.9.6 (32 bit)
ssh (64 bit) depends on debconf (32 _or_ 64 bit)
libssl096-dev depends on libssl0.9.6 (32 _and_ 64 bit??)
> Of course, that's only the dpkg side of things; in any case, you'd still
> need a way to present the extra choices caused by legal-archs in
> dselect. How would that be done?
One way is to copy the system that rpm is using: every installation
sets the default architecture and the package manager has a static
translation tree with entries like this:
ia64 -> i686
x8664 -> athlon
athlon -> amdk6
athlon -> i686
amdk6 -> i586
i686 -> i586
i586 -> i486
i486 -> i386
When apt looks for a binary it starts at the configured architecture
and moves down the tree and installs the first available package it
can find.
Arnd <><
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+lZpx5t5GS2LDRf4RAliQAJ4qyazmyTV/L49uTQUnO26JPecFwACgiLZQ
zEVvf06loHkSWnN4smRD9aY=
=UGTw
-END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 04:50:59PM +0100, Hamish Marson wrote: > Ah right. Light dawneth. Yes, you make excellent sense. Basically ia32 > is so hacked about & wacky (In order to be backwardly compatible) as to > be very slow, yet ia64 is a new instruction set with none of the baggage > that it had to carry around. Thus you can optimise ia64 architecture > better than ia32. Yep, that's pretty much it. But ia64 != x86-64 ... ia64 is the Intel Itanium's instruction set, while x86-64 is the AMD Opteron/Athlon 64, and they're very very different beasts. The x86-64 architecture really is just another extension of the x86 architecture (and so retains all the scary stuff that's been in there from the dawn of time for backwards compatibility) ... but it does add in a few nice features that make life easier for the compiler. IA64 would take some time to explain in full, but in short it's completely incompatible with x86 (of any sort), and is based on an idea called VLIW where multiple instruction "bundles" are issued together and more responsibility is placed on the compiler's instruction scheduler to extract parallelism from the instruction stream. > Compared to something like PowerPC (Sparc maybe? Although I don't think > Sparc was concieved as a 64 bit instruction set was it? I could be wrong > there though) where you start with a 64-bit definition and then cut it > back to 32-bit & so gain some optimisations which make 32-bit PowerPC > faster than 64-bit PowerPC (Except where you genuinely need 64bit of > course). Really it's that when you're in 64-bit mode you use 64-bit operands for many operations (particularly pointers and pointer arithmetic), and it takes more time to do 64-bit math than 32-bit math (c.f. on Opteron a 32-bit multiply has a 3-cycle latency, but a 64-bit mul has a 5-cycle latency). Furthermore, in 64-bit mode you put more stress on the memory subsystem because you're loading and storing some non-zero number of 64-bit data chunks that would have been smaller (probably 32 bits in size) in 32-bit mode. All that to say that if you can do something in 32-bit mode and all other things are equal, 32-bit operations are more efficient than 64-bit operations for many cases ... there's less bits to work on. In the case of x64-64, all things are *not* equal :), and the extra registers and such tends to offset the extra overhead of dealing with 64-bit operands. Or so AMD has said. Also, in 64-bit mode AMD left sizeof(int)==4 so that the overhead of 64-bit integer operations isn't incurred for many code paths that don't need it. They also made some noise about changing the C calling convention around and supposedly it's more efficient now, but I don't know much in the way of details on that. -- Anderson MacKay <[EMAIL PROTECTED]> Green Hills Software -- Hardware Target Connections
Re: Debian for x86-64 (AMD Opteron)
Hi, On Thu, Apr 10, 2003 at 05:27:40PM +0200, Michael Banck wrote: > On Thu, Apr 10, 2003 at 04:43:57PM +0200, Emile van Bergen wrote: > > On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote: > > > > [SNIP] > > > So basically, I don't think this is a very good idea. However I think we > > > can solve it differently in a much simpler way: > > > > > > * modify dpkg (already planned) to allow it to install packages from > > > different architectures on a system where it makes sense > > > * change the naming of the libraries, for example by adding '64' to the > > > 64bit version of a library > > > > > > That way you could do something like: > > > > > > # echo x86-64 >> /etc/dpkg/legal-archs > > > # dpkg -i libgtk2-2.0-1_i386.deb > > > # dpkg -i lib64gtk2-2.0-1_x8664.deb > > > > To my untrained eye, this seems an excellent and very general solution. > > > > As a slight but positive side effect, it also seems to open the way to > > per-CPU optimized library versions; if you have a 686, you add 686 (or > > 686-cmov) to /etc/dpkg/legal-archs, and can install either > > > > libssl0.9.6-0.9.6c-2_i386.deb or > > libssl0.9.6-0.9.6c-2_i686.deb; > > > > on a x86-64 you'd have the choice between those same two plus > > > > libssl0.9.6-0.9.6c-2_x8664.deb > > Please note the > wiggy> * change the naming of the libraries, for example by adding '64' to > wiggy> the 64bit version of a library > > Your above examples all have the same package name, just for a different > architecture. AFAICT, this is exactly what Wichert wanted to avoid. Yes, sorry, the last .deb name should have been lib64ssl0.9.6-0.9.6c-2_x8664.deb; it's a different package altogether, and applications need an explicit dependency on it. The other two were correct; the package name is the same, they conflict inherently, and applications cannot specify any particular dependency. The positive side of that is that the rollout of CPU optimized versions of library can happen without having to change depending applications in any way. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpiNsZ31ItHK.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Le Thu, Apr 10, 2003, à 03:33:39PM +0200, Wichert Akkerman a écrit: > That way you could do something like: > > # echo x86-64 >> /etc/dpkg/legal-archs > # dpkg -i libgtk2-2.0-1_i386.deb > # dpkg -i lib64gtk2-2.0-1_x8664.deb Will we have to also have lib64gtk2.0-dev? Wouldn't that have pretty bad inconvenient consequences on the build dependencies? -- Cyrille --
Re: Debian for x86-64 (AMD Opteron)
Andy MacKay wrote: On Thu, Apr 10, 2003 at 12:43:38PM +0100, Colin Watson wrote: On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote: Le Thu, Apr 10, 2003, ? 10:40:47AM +0100, Hamish Marson a ?crit: I'm not sure how your logic works out that a 64 bit reg is going to be faster than a 32bit one. Or do you mean simply you're expecting a speedu because there are MORE 64 bit registers tahn 32 bit registers? Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 (IIRC, long is 64 bit and of course any T* ). So yes, anything which plays with pointers will be larger on x86-64, but it's not an automatic doubling in size of everything. And mapping libraries twice also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or 64-bit registers (not even counting a large SSE2 register file as well) should help gcc feel more at home (especially with less code dedicated to handling register<->memory swap-outs) I don't have numbers to back either choice, but it looks to me that a mixed userland with everything duplicated should be a last resort. And I'm sure some people have numbers out these. Based on the numbers I've seen, the factors mentioned seem to balance each other out fairly well. I'm not (yet) allowed to talk about the details though ... No need to be secretive. :) In Fred Weber's MPF presentation last year he put up some specific numbers about how code generation was affected by going to 64-bit mode. As I recall he said that the average instruction length increased slightly and static data size increased (larger pointers), but both the static and dynamic instruction counts went down because of the decrease in register spilling, and that generally offset the bloating effect of having larger pointers. I think the general consensus on the has been that on x86-64, compiling for 64-bit mode is seldom a performance loss and often a performance win. This is contrary to other mixed 32/64-bit architectures, usually because in those cases the 32-bit arch that the 64-bit arch was based on wasn't as archtecturally hamstrung in the first place as x86 is. Does what I've said jive with what you're seeing, in a very high-level sense? I don't want to get you in trouble with the NDA police or anything. :) Ah right. Light dawneth. Yes, you make excellent sense. Basically ia32 is so hacked about & wacky (In order to be backwardly compatible) as to be very slow, yet ia64 is a new instruction set with none of the baggage that it had to carry around. Thus you can optimise ia64 architecture better than ia32. Compared to something like PowerPC (Sparc maybe? Although I don't think Sparc was concieved as a 64 bit instruction set was it? I could be wrong there though) where you start with a 64-bit definition and then cut it back to 32-bit & so gain some optimisations which make 32-bit PowerPC faster than 64-bit PowerPC (Except where you genuinely need 64bit of course). -- I don't suffer from Insanity... | Linux User #16396 I enjoy every minute of it... | | http://www.travellingkiwi.com/ |
Re: Debian for x86-64 (AMD Opteron)
Hi, On Thu, Apr 10, 2003 at 05:23:12PM +0200, Cyrille Chepelov wrote: > Le Thu, Apr 10, 2003, à 04:43:57PM +0200, Emile van Bergen a écrit: > > > > That way you could do something like: > > > > > > # echo x86-64 >> /etc/dpkg/legal-archs > > > # dpkg -i libgtk2-2.0-1_i386.deb > > > # dpkg -i lib64gtk2-2.0-1_x8664.deb > > > > To my untrained eye, this seems an excellent and very general solution. > > > > As a slight but positive side effect, it also seems to open the way to > > per-CPU optimized library versions; if you have a 686, you add 686 (or > > 686-cmov) to /etc/dpkg/legal-archs, and can install either > > > > libssl0.9.6-0.9.6c-2_i386.deb or > > libssl0.9.6-0.9.6c-2_i686.deb; > > That would be > lib686ssl0.9.6-0.9.6c-2_i686.deb; > or > lib686-cmovssl0.9.6-0.9.6c-2_i686-cmov.deb; > > according to Wichert's proposal (which I think will lead us to a support > nightmare, not to mention the ugliness of the naming scheme) No, for dependency-less optimizations you leave them out on purpose; that's the whole idea. You want 32-bit applications that depend on libssl0.9.6, to use either libssl0.9.6-0.9.6c-2_i386.deb or libssl0.9.6-0.9.6c-2_i686.deb; completely transparent to the depending application. I.e. every package becomes slightly virtual in the sense that multiple architectures are allowed. Only 64-bit applications would depend on lib64ssl0.9.6 (from lib64ssl0.9.6-0.9.6c-2_x8664.deb, sorry, missed the 64 in my last mail) instead of depending on libssl0.9.6, which is an entirely different package. I'll stop rambling about this now though as optimization an entirely different subject. I just wanted to second Wichert's idea. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpTkcQvWK8uO.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 04:43:57PM +0200, Emile van Bergen wrote: > On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote: > > [SNIP] > > So basically, I don't think this is a very good idea. However I think we > > can solve it differently in a much simpler way: > > > > * modify dpkg (already planned) to allow it to install packages from > > different architectures on a system where it makes sense > > * change the naming of the libraries, for example by adding '64' to the > > 64bit version of a library > > > > That way you could do something like: > > > > # echo x86-64 >> /etc/dpkg/legal-archs > > # dpkg -i libgtk2-2.0-1_i386.deb > > # dpkg -i lib64gtk2-2.0-1_x8664.deb > > To my untrained eye, this seems an excellent and very general solution. > > As a slight but positive side effect, it also seems to open the way to > per-CPU optimized library versions; if you have a 686, you add 686 (or > 686-cmov) to /etc/dpkg/legal-archs, and can install either > > libssl0.9.6-0.9.6c-2_i386.deb or > libssl0.9.6-0.9.6c-2_i686.deb; > > on a x86-64 you'd have the choice between those same two plus > > libssl0.9.6-0.9.6c-2_x8664.deb Please note the wiggy> * change the naming of the libraries, for example by adding '64' to wiggy> the 64bit version of a library Your above examples all have the same package name, just for a different architecture. AFAICT, this is exactly what Wichert wanted to avoid. Michael
Re: Debian for x86-64 (AMD Opteron)
Previously Emile van Bergen wrote: > As a slight but positive side effect, it also seems to open the way to > per-CPU optimized library versions; That's why we were already planning to do it. To make that really useful one could extend apt and add a priority to each supported architecture so it can pick the one that is preferred for your system. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 12:43:38PM +0100, Colin Watson wrote: > On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote: > > Le Thu, Apr 10, 2003, ? 10:40:47AM +0100, Hamish Marson a ?crit: > > > I'm not sure how your logic works out that a 64 bit reg is going to > > > be faster than a 32bit one. Or do you mean simply you're expecting a > > > speedu because there are MORE 64 bit registers tahn 32 bit > > > registers? > > > > Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 > > (IIRC, long is 64 bit and of course any T* ). So yes, anything which > > plays with pointers will be larger on x86-64, but it's not an > > automatic doubling in size of everything. And mapping libraries twice > > also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or > > 64-bit registers (not even counting a large SSE2 register file as > > well) should help gcc feel more at home (especially with less code > > dedicated to handling register<->memory swap-outs) > > > > I don't have numbers to back either choice, but it looks to me that a > > mixed userland with everything duplicated should be a last resort. And > > I'm sure some people have numbers out these. > > Based on the numbers I've seen, the factors mentioned seem to balance > each other out fairly well. I'm not (yet) allowed to talk about the > details though ... No need to be secretive. :) In Fred Weber's MPF presentation last year he put up some specific numbers about how code generation was affected by going to 64-bit mode. As I recall he said that the average instruction length increased slightly and static data size increased (larger pointers), but both the static and dynamic instruction counts went down because of the decrease in register spilling, and that generally offset the bloating effect of having larger pointers. I think the general consensus on the has been that on x86-64, compiling for 64-bit mode is seldom a performance loss and often a performance win. This is contrary to other mixed 32/64-bit architectures, usually because in those cases the 32-bit arch that the 64-bit arch was based on wasn't as archtecturally hamstrung in the first place as x86 is. Does what I've said jive with what you're seeing, in a very high-level sense? I don't want to get you in trouble with the NDA police or anything. :) -- Anderson MacKay <[EMAIL PROTECTED]> Green Hills Software -- Hardware Target Connections
Re: Debian for x86-64 (AMD Opteron)
Hi, On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote: [SNIP] > So basically, I don't think this is a very good idea. However I think we > can solve it differently in a much simpler way: > > * modify dpkg (already planned) to allow it to install packages from > different architectures on a system where it makes sense > * change the naming of the libraries, for example by adding '64' to the > 64bit version of a library > > That way you could do something like: > > # echo x86-64 >> /etc/dpkg/legal-archs > # dpkg -i libgtk2-2.0-1_i386.deb > # dpkg -i lib64gtk2-2.0-1_x8664.deb To my untrained eye, this seems an excellent and very general solution. As a slight but positive side effect, it also seems to open the way to per-CPU optimized library versions; if you have a 686, you add 686 (or 686-cmov) to /etc/dpkg/legal-archs, and can install either libssl0.9.6-0.9.6c-2_i386.deb or libssl0.9.6-0.9.6c-2_i686.deb; on a x86-64 you'd have the choice between those same two plus libssl0.9.6-0.9.6c-2_x8664.deb Of course, that's only the dpkg side of things; in any case, you'd still need a way to present the extra choices caused by legal-archs in dselect. How would that be done? Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgprxcutj0URl.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Previously Michael Banck wrote:
> [just replying to bring this to the attention of the dpkg-maintainers.
> At least Wichert does not read -devel. I hope that's alright.]
Sure.
On Thu, Apr 10, 2003 at 10:12:25AM +0900, GOTO Masanori wrote:
> I think generic 64bit libraries should put on {/lib64, /usr/lib64/,
> /usr/local/lib64, /usr/X11R6/lib64, ...}. Debian 64bit architecture
> packages should have only 64 bit libraries because it saves storage,
> and once we prepare 64bit port, we have no need to use 32bit
> binaries/libraries. To use 32 bit old libraries, dpkg and apt may
> be needed to modify handling both 32 bit and 64 bit packages like:
>
> apt-get install libgtk2.0-0(32) libgtk2.0-0
> dpkg -i libgtk2.0-0_ver_i386.deb libgtk2.0-0_ver_x8664.deb
I don't think that would work: you suddenly have two packages with
the exact same name and version, only with a different architecture.
This would mean that suddenly everywhere there would be an implicit
extra key in identifying a package: besides its name and version
the architecture would be important.
This would mean major changes to how things work:
* dpkg, apt and others would need to store the architecture for each
package after installation
* all code that deals with package relations needs to be updated to
check architectures
* dpkg would have to allow two different versions of the same package
to be installed
Since dependencies do not specify an architecture we could also run into
all sorts of problem when trying to resolve them.
So basically, I don't think this is a very good idea. However I think we
can solve it differently in a much simpler way:
* modify dpkg (already planned) to allow it to install packages from
different architectures on a system where it makes sense
* change the naming of the libraries, for example by adding '64' to the
64bit version of a library
That way you could do something like:
# echo x86-64 >> /etc/dpkg/legal-archs
# dpkg -i libgtk2-2.0-1_i386.deb
# dpkg -i lib64gtk2-2.0-1_x8664.deb
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 12:43:38PM +0100, Colin Watson wrote: > On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote: > > Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 > > (IIRC, long is 64 bit and of course any T* ). So yes, anything which > > plays with pointers will be larger on x86-64, but it's not an > > automatic doubling in size of everything. And mapping libraries twice > > also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or > > 64-bit registers (not even counting a large SSE2 register file as > > well) should help gcc feel more at home (especially with less code > > dedicated to handling register<->memory swap-outs) > > > > I don't have numbers to back either choice, but it looks to me that a > > mixed userland with everything duplicated should be a last resort. And > > I'm sure some people have numbers out these. > > Based on the numbers I've seen, the factors mentioned seem to balance > each other out fairly well. I'm not (yet) allowed to talk about the > details though ... (And what I mean by this is that the x86-64 seems to have bloody good 32-bit performance, not poor 64-bit performance. :)) -- Colin Watson [EMAIL PROTECTED]
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote: > Le Thu, Apr 10, 2003, ? 10:40:47AM +0100, Hamish Marson a ?crit: > > I'm not sure how your logic works out that a 64 bit reg is going to > > be faster than a 32bit one. Or do you mean simply you're expecting a > > speedu because there are MORE 64 bit registers tahn 32 bit > > registers? > > Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 > (IIRC, long is 64 bit and of course any T* ). So yes, anything which > plays with pointers will be larger on x86-64, but it's not an > automatic doubling in size of everything. And mapping libraries twice > also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or > 64-bit registers (not even counting a large SSE2 register file as > well) should help gcc feel more at home (especially with less code > dedicated to handling register<->memory swap-outs) > > I don't have numbers to back either choice, but it looks to me that a > mixed userland with everything duplicated should be a last resort. And > I'm sure some people have numbers out these. Based on the numbers I've seen, the factors mentioned seem to balance each other out fairly well. I'm not (yet) allowed to talk about the details though ... -- Colin Watson [EMAIL PROTECTED]
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 10 April 2003 12:16, Ulrich Eckhardt wrote: > Other alternative: only install and run 32bit apps in a chroot-style > thingy, 64bit stuff being the native type. Is that useful/possible ? Possible -- sure, but not useful except as an option for the initial bootstrap that might not fully work with /lib64. I've followed both SuSE and Red Hat making that mistake with their early s390x distributions. They both now have the problem that they changed to /lib64 installations, which makes it really hard to create 64 bit packages that work in the old _and_ new distributions. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lVan5t5GS2LDRf4RAoqhAJsE5Xc2Vjsad4yNx5tZKgLnzTt0BwCfTWru X2fM5E1MB0Oh8Zhh9LHJj9c= =HKhC -END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
Hamish Marson <[EMAIL PROTECTED]> writes: > I'm not sure how your logic works out that a 64 bit reg is going to be > faster than a 32bit one. Or do you mean simply you're expecting a > speedu because there are MORE 64 bit registers tahn 32 bit registers? IIRC x86-64 has 8 additional registers, which helps *alot* given the very few registers ia32 has. Gerd -- Gerd Knorr <[EMAIL PROTECTED]>
Re: Debian for x86-64 (AMD Opteron)
Le jeu 10/04/2003 à 11:40, Hamish Marson a écrit : > Then again, it's more likely to end up SLOWER as loading 64 bit values > from memory into registers is going to go at half the speed of loading > 32 bit values, just based on bus bandwidth alone. If the system you're > supporting does BOTH 32 & 64 bit at the same time, then unless you need > > 2GB access, 32bit is probably going to be the way to go. AIUI, this is true for e.g. sparc64, but not for x86_64. The opteron is not just an i386 with 64 bit registers, but has new registers and new optimizations which make it run faster with 64 bit executables than with 32 bit ones. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Le Thu, Apr 10, 2003, à 10:40:47AM +0100, Hamish Marson a écrit: > I'm not sure how your logic works out that a 64 bit reg is going to be > faster than a 32bit one. Or do you mean simply you're expecting a speedu > because there are MORE 64 bit registers tahn 32 bit registers? Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 (IIRC, long is 64 bit and of course any T* ). So yes, anything which plays with pointers will be larger on x86-64, but it's not an automatic doubling in size of everything. And mapping libraries twice also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or 64-bit registers (not even counting a large SSE2 register file as well) should help gcc feel more at home (especially with less code dedicated to handling register<->memory swap-outs) I don't have numbers to back either choice, but it looks to me that a mixed userland with everything duplicated should be a last resort. And I'm sure some people have numbers out these. Assuming a pure x86-64 (no 32 bit support) can be bootstrapped with relative ease, I guess it would be very interesting to see a couple benchmark (speed and memory) numbers against running the exact same package selection but from the i386 archive. It looks to me that the /lib-vs-/lib64 scheme should have enough room to let people make the right tradeoff between running full 32-bit (but allegedly smaller in data sizes), full 64-bit (but allegedly faster in code in some situations, and probably slightly larger in data size) or a mixture (obviously mapping common libraries twice), using their own workloads. -- Cyrille --
Re: Debian for x86-64 (AMD Opteron)
On Thursday 10 April 2003 03:12, GOTO Masanori wrote:
> I think generic 64bit libraries should put on {/lib64, /usr/lib64/,
> /usr/local/lib64, /usr/X11R6/lib64, ...}. Debian 64bit architecture
> packages should have only 64 bit libraries because it saves storage,
> and once we prepare 64bit port, we have no need to use 32bit
> binaries/libraries. To use 32 bit old libraries, dpkg and apt may
> be needed to modify handling both 32 bit and 64 bit packages like:
>
> apt-get install libgtk2.0-0(32) libgtk2.0-0
> dpkg -i libgtk2.0-0_ver_i386.deb libgtk2.0-0_ver_x8664.deb
Other alternative: only install and run 32bit apps in a chroot-style thingy,
64bit stuff being the native type. Is that useful/possible ?
Uli
Re: Debian for x86-64 (AMD Opteron)
Philippe Troin wrote: Ben Collins <[EMAIL PROTECTED]> writes: On Wed, Apr 09, 2003 at 09:58:04PM +0200, Arnd Bergmann wrote: Note that the x86_64 is special: It would be relatively easy to bootstrap a port on the actual hardware, but doing it right requires changing _all_ library packages as well as many other packages. The problem is that we want binaries to be compatible with i386 as well as with other x86_64 distributions and that requires the installation of both 32 and 64 bit libraries at the same time. IMO, the right way is just like ia64 is doing. 64bit userspace with an ia32 subarch installable. Best part about this is that you can use almost everything ia64 is doing already. In fact, if dpkg could support ia32 packages as a subarch for ia64 and x86_64, the packages could be installable on both as-is. I definitely prefer everything 64-bit with optionally 32-bit rather than the other way around. Otherwise what's the point? Plus, as another poster wrote, 64-bit executable might end-up being faster because of the extra 64-bit-only registers. Phil. Then again, it's more likely to end up SLOWER as loading 64 bit values from memory into registers is going to go at half the speed of loading 32 bit values, just based on bus bandwidth alone. If the system you're supporting does BOTH 32 & 64 bit at the same time, then unless you need > 2GB access, 32bit is probably going to be the way to go. I'm not sure how your logic works out that a 64 bit reg is going to be faster than a 32bit one. Or do you mean simply you're expecting a speedu because there are MORE 64 bit registers tahn 32 bit registers? H -- I don't suffer from Insanity... | Linux User #16396 I enjoy every minute of it... | | http://www.travellingkiwi.com/ |
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 10 April 2003 03:46, Philippe Troin wrote: > > IMO, the right way is just like ia64 is doing. 64bit userspace with an > > ia32 subarch installable. Best part about this is that you can use > > almost everything ia64 is doing already. In fact, if dpkg could support > > ia32 packages as a subarch for ia64 and x86_64, the packages could be > > installable on both as-is. > > I definitely prefer everything 64-bit with optionally 32-bit rather > than the other way around. Otherwise what's the point? There is a difference between the two questions of where to install libraries and whether to do a full native port. AFAIK, debian/ia64 only has a very limited support for i386 packages because it requires i386 libraries to be installed below /emul/ia32-linux/. The existing x86_64 (and newer s390x, for that matter) distributions take a different approach. Native 64 bit libraries are installed in /lib64 and /usr/lib64 instead of /lib and /usr/lib. This makes it possible to install all libraries in both variants at the same time. Applications can obviously be installed only once, but that is what is desired anyway. The scheme is consistant with LSB and is the only one that provides full binary compatibility with Debian/i386 _and_ RPM packages from other distros. We should definitely do a port of all packages to native 64 bit, but in the process of doing so, we can use any i386 packages that are not yet ported. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lTvJ5t5GS2LDRf4RAouzAKCMde7VX1HW/obqnxwOMInwNI8EJgCbB8E3 OlSqaArlFYX0q5GPQO2fo6g= =iqhN -END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 10 April 2003 03:24, Falk Hueffner wrote: > On x86-64, things might be a bit different, though, because the 64 bit > variant has more registers and therefore gcc might produce better code > and binaries might run faster. If that is the case, 64 bit libraries > and programs would generally be preferable. I don't know whether it is > actually the case, though. It would be preferrable to have full 64 bit userspace for the other ports as well. I know that on s390x, many users want to have more than 2GB virtual addressing space and 64 bit only userspace is usually faster than mixed 32/64 bit space because you don't have to map all libraries twice. We are definitely working towards a native s390x port, probably other 64 bit ports aside from x86_64 and s390x are as well. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lTb55t5GS2LDRf4RAgTTAJ0c4KmX0R/qfPHcfKhTyO0Efc2T6gCgoS/3 8jW6qgGJbj+wuLqMhgMdNFY= =YOU3 -END PGP SIGNATURE-
Re: Debian for x86-64 (AMD Opteron)
[just replying to bring this to the attention of the dpkg-maintainers.
At least Wichert does not read -devel. I hope that's alright.]
On Thu, Apr 10, 2003 at 10:12:25AM +0900, GOTO Masanori wrote:
> At Wed, 9 Apr 2003 23:08:31 +0200,
> Michael Banck wrote:
> > > Note that the x86_64 is special: It would be relatively easy to bootstrap
> > > a port on the actual hardware, but doing it right requires changing _all_
> > > library packages as well as many other packages. The problem is that
> > > we want binaries to be compatible with i386 as well as with other x86_64
> > > distributions and that requires the installation of both 32 and 64 bit
> > > libraries at the same time.
> >
> > FWIW, we can probably discuss how to do an x86-64 port in the right
> > way[tm] *NOW*, we don't need access the hardware for this.
>
> I fully agree.
>
> Moreover, this discussion is needed for architectures which can handle
> both 32bit and 64bit binaries for a long time. Currently glibc has
> already sparc64 and s390x port, but we will have x86_64, in addition
> probably ppc64 and mips64 (I have been interested in this area
> especially for maintaining glibc package).
>
> Currently only glibc and gcc has special handling for sparc64 and
> s390x. Almost all libraries are not concerned, so most applications
> on sparc64 and s390x are worked under 32bit. 32 bit is sufficient for
> almost personal users, but it's not for commercial use and probably
> future personal use (for handling large DVD/blueray movie data or so).
>
> I think generic 64bit libraries should put on {/lib64, /usr/lib64/,
> /usr/local/lib64, /usr/X11R6/lib64, ...}. Debian 64bit architecture
> packages should have only 64 bit libraries because it saves storage,
> and once we prepare 64bit port, we have no need to use 32bit
> binaries/libraries. To use 32 bit old libraries, dpkg and apt may
> be needed to modify handling both 32 bit and 64 bit packages like:
>
> apt-get install libgtk2.0-0(32) libgtk2.0-0
> dpkg -i libgtk2.0-0_ver_i386.deb libgtk2.0-0_ver_x8664.deb
>
> Well the version number "ver" should be same in 32/64 bit version.
> The above issue is only for generic libraries, and I have not
> considered how to handle glibc/gcc package yet.
>
> BTW, my concern about x86_64 issue is intel's 64bit extension (not
> ia64). If they plan to release 64 bit version i386, and it's
> different architecture from x86_64 (so XEAX is not existed, for
> example), we should not think that x86_64 is only 64 bit version of
> i386 (and i386 packages are shared between x86_64 and intel's i386
> 64bit).
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 10:12:25AM +0900, GOTO Masanori wrote: > already sparc64 and s390x port, but we will have x86_64, in addition > probably ppc64 and mips64 (I have been interested in this area > especially for maintaining glibc package). And hppa64. -- chris jantzen kb7rnl =-> __O Insert witty comment here. _`\<,_ http://www.maybe.net/ (*)/ (*)
