Florian Weimer <[EMAIL PROTECTED]> wrote:
>
> The slowdown is a price to be paid, otherwise we would need a
> different set of almost all shared libraries for linking with
> multi-threading programs. I think we already had this situation, and
> it wasn't nice at all.
No you don't, all you need
> > dpkg: error processing /var/cache/apt/archives/libc6-sparc64_2.2.5-11.2_sparc.deb
>(--unpack):
> > trying to overwrite `/usr/lib/64', which is also in package fakeroot
> > Errors were encountered while processing:
> > /var/cache/apt/archives/libc6-sparc64_2.2.5-11.2_sparc.deb
> > E: Sub-pro
Hi,
If anyone has run my findsyms perl script..
http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00148.html
http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00164.html
...and has results for a particular arch, they may want to share this
information upstream wi
Carlos,
I thought someone told me that the debian packages
for hppa had been run through my findsyms perl script
and that no undefined libgcc symbols were detected in
any of the binaries or libraries? If that is the case
you don't need a libgcc-compat at all.
Jack
> Carlos,
>It looks like Ulrich is preparing to kick out glibc shortly
> and roll any remaining fixes into glibc 2.3.1...
>
> http://sources.redhat.com/ml/libc-hacker/2002-09/msg00072.html
>
> Is hppa building cleanly and passing all of make check from
> current glibc cvs? If not you might w
Carlos,
It looks like Ulrich is preparing to kick out glibc shortly
and roll any remaining fixes into glibc 2.3.1...
http://sources.redhat.com/ml/libc-hacker/2002-09/msg00072.html
Is hppa building cleanly and passing all of make check from
current glibc cvs? If not you might want to push any
Processing commands for [EMAIL PROTECTED]:
> reassign 162663 gnumach-dev
Bug#162663: libc0.3-dev: depends on gnumach-dev which is priority optional
Bug reassigned from package `libc0.3-dev' to `gnumach-dev'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bu
On Sat, Sep 28, 2002 at 07:34:35AM +, Brian M. Carlson wrote:
> libc0.3-dev is priority standard. gnumach-dev is priority optional.
> libc0.3-dev Depends: on gnumach-dev, which is forbidden. One of the
> two priorities needs to be adjusted, so that it no longer violates
> policy, or else libc
Ben Collins <[EMAIL PROTECTED]> writes:
> Question is, is it really that much overhead? I can't see many
> applications having references to errno become a bottleneck for
> performance. If they do, then they should probably be rewritten anyway
The slowdown is a price to be paid, otherwise we wou
On Fri, Sep 27, 2002 at 03:46:34PM +0900, Julian Stoev wrote:
> Today's SPARC upgrade is broken.
>
> dpkg: error processing /var/cache/apt/archives/libc6-sparc64_2.2.5-11.2_sparc.deb
>(--unpack):
> trying to overwrite `/usr/lib/64', which is also in package fakeroot
> Errors were encountered wh
Package: libc0.3-dev
Version: 2.2.5-13 (not installed)
Severity: serious
Justification: Policy 2.2
libc0.3-dev is priority standard. gnumach-dev is priority optional.
libc0.3-dev Depends: on gnumach-dev, which is forbidden. One of the two
priorities needs to be adjusted, so that it no longer viol
11 matches
Mail list logo
