for x86-64 (AMD
Opteron) previous discussion
(My 2 euro cents remark)
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
-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
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
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
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,
-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
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
-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
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
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
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
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
( 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
-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,
* 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
On Sat, 2003-04-12 at 02:02, Eduard Bloch wrote:
#include hallo.h
* 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
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
#include hallo.h
* 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
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 ;-).
-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,
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
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]
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
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
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
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.
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
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
* 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
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
#
-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:
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
-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
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
[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
-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,
-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
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
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
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
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
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
-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
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
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
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,
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
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.
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
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
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
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
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
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
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
-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
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
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
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
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
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
62 matches
Mail list logo
