Bug#190399: glibc: should support x86-64
Hi,
Sorry my late reply - I've noticed to lost my forgot to send the reply.
At Mon, 28 Apr 2003 18:15:58 +0200,
Arnd Bergmann wrote:
> On Monday 28 April 2003 05:51, GOTO Masanori wrote:
>
> > Well, that's right. BTW, I still wonder how to support IA32 binaries.
> > You're planning to support x86-64 native package with this patch for
> > the present?
> No, this patch is meant to bring i386/amd64 to the point where s390 and
> sparc are. Support for native packages is one of the next steps. I want
> to do s390x and amd64 at the same time, even if s390x might stay out of
> the official Debian mirrors.
OK, I could understand the current status and your direction.
It's really nice to support sparc64/s390x/amd64 at the same time.
> > As we discussed a few week ago, is dpkg change needed?
> The most important change that is required for dpkg is to make it
> possible to mix 64 and 32 bit packages on i386/amd64 (and s390{,x},
> for that matter). It looks like we also need a new field in the
> control file to better handle the naming of packages, e.g.
>
> Package: libncurses5
> AltPackage: lib64ncurses5
>
> Another change that might be helpful is to have an 'Architecture:
> anylib64' and 'Architecture: anylib' or similar option that can
> either be expanded by dpkg-gencontrol or identified by dpkg and
> apt.
It's difficult for me to judge that this 32/64 bit biarch support is
really fine or not. However, I understand dpkg should support this
kind of new biarch framework.
> > If you have "roadmap" or "policy" to support x86-64, could you tell
> > us?
> Gerhard Tonn is currently experimenting with some options on an s390x
> system. It is not sure if it works out like this, but our current
> idea is roughly:
>
> - - Fix autoconf to set ${libdir} correctly on 64 bit systems
> - - Add a dpkg-libinfo program similar to dpkg-architecture that
> knows about library paths etc.
> - - Make dpkg know about the extra features in the control files.
> - - Add support for automatically detecting /lib64 paths to
> dh_install, dh_movefiles and dh_installdirs. They will try
> to do the right thing and give a warning if the packager
> e.g. wrote /usr/lib/* instead of $(libdir)/* or /usr/lib64/*.
> - - Convert all 'required' and 'important' library packages to a dual
> lib / lib64 system. They must be installable for both 64 and 32
> bit at the same time.
> - - Make all 'standard' packages build with 64 bit. Standard libraries
> should be installable for both 64 and 32 bit at the same time.
> - - 64 bit library packages should be named like lib64foo3
> - - Build-essential -dev packages should allow being installed for both
> 64 and 32 bit, the names should be like lib64foo3-dev.
> - - Non-build-essential -dev packages should have the same name for
> 64 and 32 bit packages (e.g. libfoo3-dev) because of the dependencies
> on them.
>
> Gerhard is trying this on an s390x machine, starting from a working
> /lib based system, I'll start with an i386 system running on an Opteron
> once I get access.
Thanks for your explanation in detail. Your idea is really nice. *cheer*
> > My concern is that if we use "/lib64", and all other binaries are also
> > use "/lib64", but debian libraries are usually put on "/lib". Are there
> > any problems of the difference between "/lib64" and "/lib"?
> The run-time linker already knows about /lib64 and most packages
> using hardcoded /usr/lib path for dlopen etc. are being fixed already
> or have patches available from SuSE.
>
> There will be problems, but most of them can be solved by fixing libtool
> and autoconf. What remains are hardcoded paths in many debian/rules
> and debian/*.files files. Some can be dealt with with debhelper, others
> have to be changed.
Well... I guess it becomes large amount of works (because debian ships
a lot of packages compared with other distros). One way to reduce
your work, we introduce DEB_LIBRARY_PATH which is replaced with /lib
on 32bit and /lib64 on 64bit architectures in debian/rules.
> > This problem was modified on s390. S390 does not have generate-asm.sh,
> > and Gerhard Tonn sent me the nice patch to fix it. Please look at
> > the current debian-glibc cvs, or sooner available 2.3.2-1.
>
> I know about this, Gerhard sits next door and I gave him the patch.
OK.
> > > +ifeq ($(DEB_HOST_GNU_CPU),i386)
> >
> > Umm, why is it "i386"? Should be "x86-64"?
>
> Like on s390x, the debian architecture name is still the 32 bit one.
> Until dpkg knows about the relation between 64 and 32 bit architectures,
> we cannot make native 64 bit packages. Later, this will be
> i386 || amd64 || s390 || s390x || sparc || sparc64
> or rather, checking a different variable.
I see.
> > > # debian/sysdeps/linux.mk are simple duplications of the respective s390x
> > > # versions. The name for the 64 bit package, however is not libc6-x64-64
> > 86
> Of course. Probably better 'amd64'.
>
> > > # but lib64c6. I think it would be a good idea to rename the s390 and
> > > sparc # packages to lib64c6 as well, as that will remove some complexity
> > > from the # rules file and from dependend packages
> >
> > This seems good idea. But, hmm, do you think "libc64-6" or "libc6-64"?
> > Do you assume other 64 bit libraries also have "lib64xxx"?
> Yes, the lib64foo name was proposed by Wichert Akkerman and I think it
> is clearer than the others because it avoids putting different numbers
> in a row and it shows that it contains files in */lib64/. It's slightly
> less grepable, which I don't think is so important when everyone get's
> used to it.
Ah, that makes sense. It's fine to precede 'lib64' in the package
namespace.
> > > +Section: base
> > > +Priority: required
> > > +Depends: libc6 (= ${Source-Version})
> > > +Description: GNU C Library: 64bit Shared libraries for x86_64
> > > + This package includes shared versions of the standard C library and the
> > > + standard math library, as well as many others. This is the 64bit
> > > version + library, meant for AMD Hammer (x86_64) systems.
> > > +
> > > +Package: lib64c6-dev
> > > +Architecture: i386
> > > +Section: devel
> > > +Priority: standard
> > > +Depends: lib64c6 (= ${Source-Version}), libc6-dev (= ${Source-Version}),
> > > gcc-3.2 (>= 3.2.1-0pre1) +Description: GNU C Library: 64bit Development
> > > Libraries for x86_64 + Contains the symlinks and object files needed to
> > > compile and link programs + which use the standard C library. This is the
> > > 64bit version of the + library, meant for AMD Hammer (x86_64) systems.
> >
> > I think it's not generic description. If you think s390 and sparc64
> > are merged into 64 bit support libc6, then should be this description
> > x86_64 specific?
> I had first called the package libc6-x86-64 and forgot to change the
> description when I chose the generic name.
>
> > > Package: libc-udeb
> > > Architecture: any
> > > Section: debian-installer
> >
> > libc-udeb is needed for the next generation debian installer. We plan
> > to modify the name from libc-udeb to libc6-udeb or libc6.1-udeb
> > (<packgename><versionname>-udeb). x86_64's libc-udeb is lib64c6-udeb?
> > But currently you have no need to care about libc-udeb.
>
> There is also no need to have the boot floppies 64 bit. Ideally, it should
> be possible to just install an i386 system and then upgrade to amd64,
> or maybe even autodetect 64 bit machines during installation.
I see.
> > > +ifeq ($(DEB_HOST_GNU_CPU),i386)
> > > + arch_packages += lib64c6 lib64c6-dev
> > > +endif
> > > +
> > > ifeq ($(DEB_HOST_GNU_CPU),s390)
> > > arch_packages += $(libc)-s390x $(libc)-dev-s390x
> > > endif
> > > only in patch2:
> > > unchanged:
> >
> > It means that if build architecture is "i386", libc-64 is also made.
> > However, I wonder it's really needed.
>
> Not strictly needed, but helpful. If we want to make the i386 gcc-3.3
> package biarch-capable (which is my current approach), lib64c packages
> are needed not only for building or running 64 bit binaries but also
> as a build-dependency for gcc-3.3. Having lib64c6 packages in i386
> avoids the need for accessing the amd64 package archive on the i386
> build servers.
>
> Some amd64 users might also prefer installing an i386 debian with
> just a 64 bit kernel, for example to run a commercial database
> system that needs lots of ram. They will still need a way to
> build a kernel and initrd.
OK, it's acceptable. My concern is maintainer-specific issue:
* It needs more build time. Well, I should buy faster machine for
example Opteron, though :-)
* i386 is affected amd64 stability. If amd64 cannot build, then i386
gets FTBFS.
> > > + $(srcdir)/configure --host=x86_64-linux \
> > > + --build=i386-linux --prefix=/usr --without-cvs \
> > > + --disable-profile --enable-static --enable-kernel=2.4.0 \
> >
> > "2.4.0" should be "2.4.1". I fixed it to sparc64/s390x.
>
> Ok. Probably even 2.4.19, since I think that was when x86_64 was
> introduced in Linus' tree and we won't do any backports.
Yup - we can set 2.4.19 on x86-64. However I unify to 2.4.1 currently
due to synchronizing ABI behavior with other archs.
Well, I agree there is no need to adjust the min-kernel-version on all
architectures.
> > Are there any plans to send this patch to upstream? And could you
> Yes, that's probably a good idea.
>
> > describe the detail in the DP: Description field from 0list?
> Ok.
Thanks. If you finish your work, please resend the patch!
Regards,
-- gotom
Reply to: