Re: Instead of the amd64 GR: rudimentary amd64 support for sarge, need sponsor.
Daniel Jacobowitz <dan@debian.org> writes:
> 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.
Legaly we have all we need in sid (full source of the toolchain and
the tools to build it). So if (3) below is not done we can still use
pure64 to build the i386 image and upload it with one eye closed. I
fully agree having a i386 buildable image would be better but there
are precedences (ia32-libs) for not building straight from source.
>> 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.
I wondered about that. The method of distribution "apt-get install
ia32-libs / apt-get source ia32-libs" does not come with
source. Normaly the actual source is available (under the respective
names) but not when they already updated to a newer version. But for a
stable release the versions would match.
>> 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.
I'm fine with either.
>> 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?
There have been some reports of gcc-3.4 miscompiling the kernel but I
think that was fixed.
MfG
Goswin
Reply to: