Bug#190399: Some updates of amd64 developement
Hi,
> 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.
The port is now so far complete that you can use an existing linux
with a 64 bit kernel running to "cdebootstrap sarge /chroot
http://debian-amd64.alioth.debian.org/";. I believe all build-essential
packages (except build-essential) are there too. Thats the next step.
> > 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
On irc (debian-amd64@irc.debian.org) we discussed the dpkg subarch
support and the naming scheme. We found that dpkg should use the
compatible arch and compatible abi settings from its subarch table to
find suitable packages to resolve Depends. The difference between a
ABI compatible (libs) depends would be denoted by adding {abi} to the
name.
Further fixing dpkg to allow two packages with the same name but
different ABI to be installed in parallel we could drop the 64 in
lib64ncurses5 and all other libs completly. That would make porting
much less work.
> 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.
??? what do you mean there?
> > 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
Aparently not wnated by upstream but we came to the same conclusion.
> - - Add a dpkg-libinfo program similar to dpkg-architecture that
> knows about library paths etc.
Present.
> - - 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
The name for all archs should be the same. Different names need a lot
of changes to Build-depends lines that can't be done with shlibs magic
like Depends. Using dpkg/apt to fetch the right ABI sounds more
reasonable.
> - - Build-essential -dev packages should allow being installed for both
> 64 and 32 bit, the names should be like lib64foo3-dev.
See above.
> - - 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.
If they are not installable at the same time they have to Conflict.
> 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.
Is there a patch repository for s390 somewhere or could we move all
the patches onto debian-amd64.alioth.debian.org?
> > > +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.
sh-2.05b# dpkg-architecture
DEB_BUILD_ARCH=amd64
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux
DEB_BUILD_GNU_TYPE=x86_64-linux
DEB_HOST_ARCH=amd64
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=linux
DEB_HOST_GNU_TYPE=x86_64-linux
sh-2.05b# dpkg --print-architecture
i486
> > > +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.
I think all 64 bit compatibility packages (kernel, glibc, gcc) could
be build on amd64 once as normal amd64 packages and then repackages
with the architecture set to i386.
> From: GOTO Masanori <gotom@debian.or.jp>
>...
> 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.
Uisng subarchtable its more than just biarch. Any compatible
architecture or abi will be used. That means than on i686 the first
choise are i686 packages, if that fails i586, i486, i386 and all
archs are searched in turn. A binary-i686 repository can provides a
few selected i686 optimised packages and i686 users would get those
installed in favour of the normal i386 versions. No more need to make
mplayer-386, mplayer-586, mplayer-686, ... debs. All debs can be named
mplayer and put into their own binary-arch dir.
The full support for apt and dpkg is done now but when adding the
different subarch repositories to etc/apt/sources.list that already
works.
> > > 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.
sh-2.05b# dpkg-libinfo
DEB_LIBQUAL=64
DEB_LIBNAME=lib64
DEB_LIBDIR=/usr/lib64
DEB_LIB64_ARCH=1
Thats the helper tool currently used.
> > > > # 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.
As said above, the 64 is part of the ABI and should not be in the
package name. Problems with versioned/manual depends, build-depends,
package searches, greps, ... are then avoided. Feasability is being
tested pending the needed dpkg changes.
If that works out as expected and autoconf changes work out to the
normal way to port a library to amd64 would be:
- apt-get source
- autoreconf -i
- debuild
- fix hardcoded paths in debian/rules if any
Getting debhelper and dpkg tools aware of /lib64 should solve most of
them or give a goot idea of the actual problem.
> > 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.
I finished filling up the amd64 repository with all base packages
yesterday. To install and amd64 system directly only a few more
packages are needed, a kernel-image-amd64 and some patches to udpkg
and busybox for D-I. D-I itself can run 32bit for the near future,
porting that is very low priority.
MfG
Goswin
Reply to: