[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Instead of the amd64 GR: rudimentary amd64 support for sarge, need sponsor.



I spent some time talking with the glibc maintainers about this.  These
are all my own opinions, but the others seemed to agree with me.

I think this would be a very good idea.

On Wed, Jul 28, 2004 at 09:12:19PM +0200, Goswin von Brederlow wrote:
> Hi,
> 
> given the current sarge deadline and the opinions expressed by some of
> the release team a full amd64 port in sarge is not going to happen. So
> lets move on.
> 
> 
> What else can we do for amd64 users?
> 
> We have a fully working i386 port which works on amd64 systems too.
> What we need most now is support for:
> 
> 1. Kernel support for amd64 to run 32/64 bit binaries
> 
> I want to upload a kernel-image-2.6.7-amd64 to i386. That would be
> along the same lines as the sparc64 or s390x kernel image in sparc or
> s390 respectively. So nothing new there.

Obviously this requires a 64-bit capable GCC first.  Other than that I
think it's a good idea.

> 2. Support to run dynamically linked 64 binaries (e.g. from SuSe/RH)
> 
> What is needed is a /lib64 and /usr/lib64 directory with the core
> libraries. There already is a ia32-libs packages doing the reverse for
> ia64 and pure64. This just reverses the roles. Again nothing new.

I think this is a good idea also.  I'm slightly concerned about being
able to build them from source but we do have the precedent of
ia32-libs.  What other distributions have done for this is to also
include the source packages for the libraries in question in the source
package for the cross-libraries package.  I think that would be a
better idea, though it's a bit bigger - it's more
GPL-obligation-paranoid.

> 3. Support to compile 64 bit binaries
> 
> The kernel and libs need to be compiled somewhere. They could be build
> on pure64 and uploaded to i386 without problems but it would be nicer
> if they could be build under sarge i386 itself. This could be eigther
> a cross compiler (like the rest of the cross tool packages) or a 64bit
> native compiler. I tend to the later even if that restricts building
> those packages to an actual amd64 system.
> 
> Thesource for the toolchain is already in sarge so no GPL problems
> even if (3) is scratched.

The best thing to do here will be neither a cross compiler nor a 64-bit
native compiler.  You want a native 32-bit compiler which includes
64-bit support.  I can do this.

I don't know how we would want to build it; given the freeze it is
probably too late to build it from the GCC source package, unless we
want to build it from the gcc-3.4 source package (which presumably is
not part of base and thus not frozen).  Matthias, how do you feel about
that?

We'd still need a separate source package for binutils or to fix
the existing binutils -right now-.  That's an extremely low impact
change but a separate source package would be even lower impact, so is
probably best for Sarge.

> So who is willing to sponsor the following packages:
> 
> kernel-image-2.6.7-amd64
> amd64-libs
> amd64-libs-dev
> gcc-3.3-amd64
> gcc-3.4-amd64
> binutils-amd64
> 
> None of those are base or standard so there is no "must be today"
> rush. But it still needs to be rushed a bit.

Do you need gcc 3.3?

-- 
Daniel Jacobowitz



Reply to: