Re: -= PROPOSAL =- Release sarge with amd64
> >> > You could install a biarch glibc which supports both 32 and 64 bit
> >> > dpkg.
> > On Fri, Jul 16, 2004 at 03:20:43PM +0200, Goswin von Brederlow wrote:
> >> Which would be a completly new glibc package adding extra bloat to the
> >> already streesed mirrors.
> Raul Miller <firstname.lastname@example.org> writes:
> > We're talking about something several orders of magnitude smaller than
> > what it will take to add the amd64 port to the ftp master.
On Fri, Jul 16, 2004 at 08:04:32PM +0200, Goswin von Brederlow wrote:
> You still need and want the amd64 port. I thought you were talking
> about adding rudimentary biarch packages to the amd64 port?
The only things which would have to be biarch, as far as I can see,
are glibc, and important shared libs.
If space really is that tight, you could toss the single arch versions
of those libs to save a few 10s of megs of archive space.
> >> Did I mention that gcc/binutils will complain about any library not
> >> matching the ABI unless lib and lib64 are seperated completly,
> >> i.e. all lib packages are ported.
> >> I think that alone makes a partial port unsuitable for release.
> > I'm not sure what you're saying here. Are you saying that gcc won't
> > let you build a shared library to install in /lib if glibc is in /lib64?
> No. But the 64bit linker will give you stupid warnings about unknown
> abis in all the 32bit libs and the 32bit linked will give you warnings
> about the 64bit libs. Or it will link 32bit and 64bit code together
> and totaly screw up.
Sounds like a bug. Other packages (such as file) don't seem to
have make this mistake, it shouldn't be that hard to fix gcc.
> And configure scripts will think libs are there even if they are only
> there for the wrong arch and such stuff.
That sounds like a bug, too.
GPLed code (and anyother code which includes the full sources) could
probably be fixed by upgrading autoconf and rebuilding configure. That
wouldn't address every case, but leaving this unresolved sounds painful.
> >> port) an essential feature for the port. Its just a bonus. We know its
> >> not ia32 LSB compliant but so far it is ia32 LSB compatible (which is
> >> what you would care about as debian user).
> > That might be enough.
> Haven't heard complains to the contrary yet.
That sounds promising.