Bug#190399: glibc: should support x86-64
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
> 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.
> 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.
> 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.
> 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.
> > +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.
> > # 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.
> > +
> > +Package: lib64c6
> > +Architecture: i386
>
> "i386"? Is it for the current hack to work i386 binaries on x86-64?
See above.
> > +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.
> > +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.
> > + $(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.
> 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.
Arnd <><
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+rVPA5t5GS2LDRf4RAkJqAJ9Uv3LZIM/QcGv88Fe2SmhnE82bhgCfUvDm
qrIUEkpIYrRJsaYva9dDhFI=
=iT08
-----END PGP SIGNATURE-----
Reply to: