Re: Bug#317082: libc6-s390x: missing depends on lib64gcc1

[GOTO Masanori <gotom@debian.or.jp>]

reassign 317082 dpkg-dev
thanks

Summary:

  The bug submitted in #317082 that requests adding "Depends:
  lib64gcc1" to libc6-s390x on s390.  However the bug submitted in
  #258647 that requests removing "Depends: lib64gcc1" to libc6-sparc64
  on sparc.  Both bugs are conflicted because both libc6-s390x and
  libc6-sparc64 packages are equivalent as 64bit libc6 biarch package.

  I decided to remove "Depends: lib64gcc1" from libc6 which explains
  below.  This bug should be fixed as dpkg-dev's dpkg-shlibdeps
  handles 64 bit libraries like dpkg-cross' dpkg-shlibdeps does.

  Debian sparc and s390 people, from glibc 2.3.5-2 and until
  dpkg-shlibdeps supports 64bit libraries correctly, when you install
  biarch 64 bit binary packages, you may have some problems: installed
  binaries can't resolve 64bit libraries.  In that case, please
  install such libraries packages manually.


At Thu, 14 Jul 2005 15:26:58 +0900,
GOTO Masanori wrote:
> At Tue, 12 Jul 2005 19:44:11 +0200,
> Matthias Klose wrote:
> > GOTO Masanori writes:
> > > At Tue, 05 Jul 2005 20:09:59 -0700,
> > > Ryan Murray wrote:
> > > > libc6-s390x is missing a depends on lib64gcc1 that causes gcc to fail to link
> > > > when -m64 is used on an s390 system.
> > > >
> > > > I'm filling the bug here rather than on the gcc-VERSION packages because the
> > > > sparc64 packages have the dependency in libc6-sparc64, and not the gcc
> > > > packages.
> > > 
> > > According to #258647, the latest glibc.deb in svn already removed the
> > > "Depends: lib64gcc1" entry.  So I think it should be fixed in gcc
> > > packages instead of libc6-s390x.  How about this idea?
> > 
> > I don't know of a good way to handle the 64bit dependencies. We do not
> > want to unconditionally depend on the non-default biarch packages.
> > dh_shlibdeps doesn't work for 64bit packages, so you have to hand-code
> > all the dependencies ...
> >
> > maybe dpkg-shlibdeps could use objdump -x instead of ldd to determine
> > the needed library dependencies?
> 
> I tested this problem on sparc64, dpkg-shlibdeps detects lib64gcc1 -
> even if libc6 does not depend on it.

The actual concern suggested by Matthias was: dpkg-shlibdeps can't
resolve 64 bit libraries when the built environment uses 32 bit
kernel.

The current dpkg-shlibdeps detects dependent libraries using "ldd" and
"objdump".  However "/bin/ldd 64bit-binaries" can't work on 32bit
kernel (it's the correct behavior).  "objdump -p" can't show the
actual path because elf binary has library names, but not library
pathnames.  And dpkg-shlibdeps can't work for 64bit binaries on 32bit
environment.

The current libc6-sparc64 in sarge has "Depends: lib64gcc1".  However
this kind of manual assignment for debian/control file is a bad way.
Why is it "bad"?  Because in future we probably have more biarch
applications (ex: imagine multimedia gnome application that handles
over 4GB video data, and it has a lot of library dependencies), so
manual handling should be dropped.  I removed this dependency from
glibc 2.3.5-2 in experimental.

The correct fix discussed and suggested by Ryan, Daniel and Matthias
was: dpkg-shlibdeps should handle 64bit library dependencies even on
32 bit kernels correctly.  Actually dpkg-shlibsdeps in dpkg-cross
package should have worked nicely because it considers about 64bit
libraries.

BTW, Nikita, dpkg-shlibdeps in dpkg-cross should have additional elf64
entries for ppc64 and amd64 like:

	@crosslib64formats = ("elf64-sparc", "elf64-s390", "elf64-x86-64", "elf64-powerpc");

Regards,
-- gotom