Source: glibc
Version: 2.37-1
Previously defined hwcap search paths have been changed. Those
specified in `man 8 ld.so` are no longer accurate (bug #1050930).
Typical output on sid/i386:
% LD_DEBUG=libs LD_LIBRARY_PATH=. /bin/true
3611433: find library=libc.so.6 [0]; searching
3611433:
[CC me please]
Hi folks,
It seems glibc 2.37 has removed hwcaps search patches.
% LD_DEBUG=libs LD_LIBRARY_PATH=. /bin/true
3611433: find library=libc.so.6 [0]; searching
3611433: search path=. (LD_LIBRARY_PATH)
3611433: trying file=./libc.so.6
3611433: s
The bugzilla thread is rather long. But I took the liberty to report
the issue as grave following the comment:
https://sourceware.org/bugzilla/show_bug.cgi?id=29863#c11
Feel free to downgrade severity if my understanding is incorrect.
Thanks
Package: libc-bin
Version: 2.36-8
Severity: grave
Justification: renders package unusable
Dear Maintainer,
There is a bug in glibc 2.36 that has been fixed in 2.37. The two
links below detail the original bug report and the fix.
- Upstream bug report - https://sourceware.org/bugzilla/show_bug.cg
For later reference.
-- Forwarded message -
From: Mathieu Malaterre
Date: Tue, Sep 20, 2022 at 8:29 AM
Subject: mips: executable-stack-in-shared-library
To:
[cc me please]
Dear mips porter,
Upstream of one of my package is trying to provide a fix for the
lintian
> Now, the ia32-libs maintainers *could* include a non-NPTL build of glibc in
> ia32-libs, and then you could use LD_ASSUME_KERNEL=2.4.1 to force the use of
> this backwards-compatible glibc with the errno@GLIBC_2.0 symbol; but given
> that even the i386 port of etch isn't going to support these ap
Control: found -1 2.31-13+deb11u3
Same for bpo:
% file /lib32/libpthread-2.31.so /lib/x86_64-linux-gnu/libpthread-2.31.so
/lib32/libpthread-2.31.so:ELF 32-bit LSB shared
object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter
/lib/ld-linux.so.2,
BuildID[sha1]=e4a9da
Control: found -1 2.33-7
Here is what I see from my sid schroot (amd64) today:
% file /lib32/libpthread-2.33.so /lib/x86_64-linux-gnu/libpthread-2.33.so
/lib32/libpthread-2.33.so:ELF 32-bit LSB shared
object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter
/lib/ld-l
Package: libc-bin
Version: 2.31-13+deb11u2
Severity: normal
File: /usr/bin/iconv
Dear Maintainer,
Steps:
% wget
https://raw.githubusercontent.com/4creators/jxrlib/master/common/include/wmsal.h
% iconv -f CP1251 -t UTF-8 wmsal.h -o wmsal.h
zsh: bus error iconv -f CP1251 -t UTF-8 wmsal.h -o wmsa
On Sun, May 10, 2020 at 10:01 PM Paul Gevers wrote:
>
> Hi Adrian,
>
> On 10-05-2020 15:25, Paul Gevers wrote:
> > I'm running another check on "cannot allocate memory in static TLS
> > block" now, will take a while.
>
> Also for this one, only vtkplotter showed up.
Did you check #951704 ? This a
Package: libc6-dev
Version: 2.19-13
Severity: important
I cannot compile the following pseudo code (see attachment) it fails with:
$ g++ -ffast-math foo.cxx
In file included from /usr/include/math.h:432:0,
from foo.cxx:3:
/usr/include/x86_64-linux-gnu/bits/math-finite.h: In funct
Package: libc6-dev
Version: 2.19-11
Severity: important
ISO C99 standard (7.18.4) specifies that C++ implementations should
define UINT64_C only when
__STDC_CONSTANT_MACROS is defined.
On wheezy:
$ g++ t.cxx
t.cxx: In function ‘int main()’:
t.cxx:6:26: error: ‘UINT64_C’ was not declared in this
Package: libc6-dev
Version: 2.3.5-8
Severity: normal
One cannot use the swab function without producing a warning. Indeed
unistd.h defines it within a __USE_XOPEN ifdef, whereas this should
not be needed according to:
http://www.opengroup.org/onlinepubs/009695399/functions/swab.html
But then if
13 matches
Mail list logo
