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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
