Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages

[Jonathan Nieder]

Aurelien Jarno wrote:

> As a subsidiary question, do you know how to prevent libc6-amd64:i386 to
> be installed on a native amd64 system, but allow it on an i386 system,
> even with libc6:amd64 already installed?

Use Conflicts against dpkg:amd64, maybe. :(


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140519190928.go12...@google.com

Bug#718577: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations

[Jonathan Nieder]

tags 718577 + upstream patch
quit

Hal BugsBuster wrote:

> Do you mean that all these catastrophic overheads are no longer
> existing in libm-2.18 ?

Yes, I believe Carlos was saying that glibc 2.18 has a fix for the
performance regression, which Debian should apply:

>> commit 2506109403de69bd454de27835d42e6eb6ec3abc
>> Author: Siddhesh Poyarekar 
>> Date:   Wed Jun 12 10:36:48 2013 +0530
>>
>> Set/restore rounding mode only when needed
[...]
>> So the improvements are:
>>
>> cos: 27.9089%
>> exp: 22.6919%
>> pow: 4.01564%
>> sin: 19.1585%
>> tan: 1.96086%

Thanks for your kindness and patience, and hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130802235942.GA2945@elie.Belkin

Bug#556173: libc-bin: introduces custom manual pages / manpages package

[Jonathan Nieder]

Simon Paillard wrote:

> Do you have a position regarding this ?
[...]
> On Thu, May 23, 2013 at 11:48:51PM +0200, Simon Paillard wrote:


>> If you agree with this, the next manpages{,dev} upload will replace libc-bin
>> with appropriate version, then you can drop them.

Please go ahead.  (I'm not an eglibc maintainer, but it seems so
obviously the right thing to do that I don't mind saying that
anyway.)

If you'd like, I think it even makes sense to replace the ldconfig.8
manpage, just taking the content from the eglibc package for now.
That would avoid having to keep juggling which package has which
manpage in the future.

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130714202706.gd8...@google.com

Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high

[Jonathan Nieder]

severity 572895
tags 572895 + upstream
quit

Harald Dunkel wrote:

> AFAICS the mesa folks don't rely upon the os abi tag anymore:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=26663

Thanks.

I think this is still a bug (priority between LD_LIBRARY_PATH and
.note.ABI-tag makes .note.ABI-tag much less useful than it could
be), but it's a complex issue, so setting severity accordingly.

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130714191414.gf4...@google.com

Bug#632281: elfutils isn't finding its plugins

[Jonathan Nieder]

Hi Kurt, 

In November, 2012, you wrote (re elfutils's plugin path):

> unarchive 632281
> reopen 632281 
> #It doesnt do the right thing in case of non-multi arch now

How should $LIB be set to support this?  I'm worried that there's
no value of ORIGIN and LIB that would make

"$ORIGIN/../$LIB"

point to the right place for both plugins using and not using the
new filesystem layout.

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130713231544.ge15...@google.com

Bug#583088: error generating locales es_ES, syntax errors, no definition categorys

[Jonathan Nieder]

tags 583088 + moreinfo
quit

Hi again,

In 2010, Iker Salmón San Millán wrote:

> The same happens with kernel 2.6.32-5-686.  I cannot acces now to the others
> computers to see if i can reproduce the bug or maybe theres is something
> diferent in my laptop's configuration.
>
> It is not a problem because regenerating locales the problem disappear, but
> i am so curious now...

Sorry to have left this hanging.  Can you reproduce it still?  If
possible I would like to reproduce the problem here to isolate a
possible cause since so far I have no clue. :)

Thanks and sorry for the trouble,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130713230659.gd15...@google.com

Bug#566508: libc6: error inside of python since last security upgrade

[Jonathan Nieder]

tags 566508 + moreinfo
quit

In 2010, dan aronson wrote:

> Since I did the last security upgrade to this package I've been getting the 
> following problem often, but not always during running of a cron job.
>
> *** glibc detected *** /usr/bin/python: corrupted double-linked list: 
> 0x020dc920 ***

Thanks for reporting, and sorry for the long silence.

Are you still able to reproduce this?  If not, do you remember when it
went away?

At first glance this looks more likely to be a python bug than a libc
one, but it's hard to say, so I'd be happy if we can figure it out.

Sorry for the trouble,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130713225346.gb15...@google.com

Bug#576484: libc6-prof: segmentation fault when using profiling with pthread.

[Jonathan Nieder]

tags 576484 + moreinfo
quit

Hi,

In 2010, Witold Baryluk wrote:

> Package: libc6-prof
> Version: 2.10.2-6
> Severity: important
>
> # cat a.c  int main() { return 0; }
> # gcc -g -pg a.c -o a  -static-libgcc -lc_p
> # ./a
> Exit code 0
> # gcc -g -pg a.c -o a  -static-libgcc -lc_p -pthread
> # ./a
> Segmentation fault (core dumped)

Interesting. Can you still reproduce this?

Curious,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130713225607.gc15...@google.com

Bug#534312: upgrade of libc6 causes SEGFAULTs

[Jonathan Nieder]

tags 534312 + moreinfo
quit

Hi,

In 2009, Ulf Hermann wrote:

>> You say you are using libc6 from unstable on a lenny system. What is the
>> list of packages you tried to upgrade?
>
> I tried to install a full KDE 4.2, that's quite a lot of packages and some of
> them depend on the newer libc - I don't know which ones. Yet, that's not
> necessary to reproduce the bug. I reverted everything to plain lenny (without
> any KDE). Then everything was OK again. Then I noticed that menu itself is the
> same in lenny and unstable and ran ldd on it to find out what might be
> responsible for the crash. Then I _only_ upgraded libc and locales (like 
> stated
> above) and that's enough to make update-menus crash.

Sorry for the long silence.  Before investigating this more, I should
ask: can you still reproduce this?  If not, do you remember what change
made it go away?

Thanks and sorry for the trouble,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130713225008.ga15...@google.com

Bug#713914: Add more information why libc is not usable with Linux kernel < 2.6.32

[Jonathan Nieder]

retitle 713914 squeeze->wheezy: reminder that kernel should be >= 2.6.32 before 
upgrade
reassign 713914 release-notes
tags 713914 + wheezy
affects 713914 + libc6
quit

Hi Thomas,

Thomas Bleher wrote:

> When updating Squeeze to Wheezy, I encountered the following error on
> two separate machines:
>
>   WARNING: this version of the GNU libc requires kernel version
>   2.6.26 or later. Please upgrade your kernel before installing
>   glibc.
>
> It would be very helpful to add more information why 2.6.26 is required,
> and what would break when using an older kernel.
>
> For example:
> - Does this libc not run at all on older kernels (say because of a new
>   syscall interface used)?
> - is just one specific feature broken (say NSS)?
> - will it be much slower because of feature XY?
> - etc.

I don't think it makes sense to try to trick it into working with an
older kernel --- simpler to rebuild glibc with a different
--enable-kernel= (__LINUX_KERNEL_VERSION) value.

Based on sysdeps/unix/sysv/linux/kernel-features.h, by assuming a
kernel >= 2.6.32, glibc can rely on support for:

 - the utimensat() syscall 
 - private futexes
 - the fallocate() syscall
 - SOCK_CLOEXEC, pipe2(), eventfd2(), signalfd4(), accept4(), etc
 - the FUTEX_CLOCK_REALTIME flag
 - the AT_RANDOM auxiliary vector
 - preadv() and pwritev()
 - F_GETOWN_EX

Missing support for pipe2(), accept4(), etc would be especially
problematic.  So I'm afraid wheezy can't run without rebuilding
eglibc for this older kernel.

[...]
> The requirement for a new kernel should also really be mentioned in the
> release notes.

Reassigning to release-notes.  The introduction says

Please note that we only support and document upgrading from
the previous release of Debian (in this case, the upgrade from
6.0). If you need to upgrade from older releases, we suggest
you read previous editions of the release notes and upgrade to
6.0 first.

but I agree that it would be helpful for e.g. section 4.2 "Checking
system status" to warn about the required kernel.

Thanks for writing, and hope that helps.

Sincerely,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130624012127.GB3024@elie.Belkin

Bug#707306: libc6: unable to upgrade to 2.17 getting errors while configuring

[Jonathan Nieder]

Hi,

shirish शिरीष wrote:

> A copy of the C library was found in an unexpected directory:
>   '/lib/libdl-2.11.2.so'
[...]
> I removed the offending library copy as well as the original, quite a
> few of them before I was able to correctly install it without any
> errors :-

Where did these files come from?


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130510022200.GA11604@elie

Bug#703980: time.h: defining TIME_UTC conflicts with boost/thread/xtime.hpp enum

[Jonathan Nieder]

reassign 703980 src:boost1.49
forcemerge 701377 703980
tags 701377 + sid experimental
affects 701377 libc6-dev
quit

Dmitrijs Ledkovs wrote:

> TIME_UTC is part of C11 standard, which is more authoritative despite
> boost's prior usage.
> In boost1.49 package this is bug 701733, but it's marked won't fix as
> later versions of boost already have a fix.

Thanks!  Therefore merging.


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130326204302.gn1...@google.com

Bug#153022: [powerpc libm] exp() in directed rounding modes gives wrong results

[Jonathan Nieder]

Vincent Lefevre wrote:
> On 2013-03-03 23:49:26 -0800, Jonathan Nieder wrote:

>> Better debdiff attached.
>
> OK, but I don't know how to download the eglibc source: both
> "apt-get source eglibc/unstable" and "apt-get source -t unstable eglibc"
> download the experimental version.

Does "apt-get source libc6/unstable" work?  If it doesn't, then

  dget http://http.debian.net/debian/pool/main/e/eglibc/eglibc_2.13-38.dsc

should do the trick.

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130306013619.gb3...@google.com

Bug#153022: [powerpc libm] exp() in directed rounding modes gives wrong results

[Jonathan Nieder]

tags 153022 + upstream patch moreinfo
quit

On 2013-03-03 16:33:45 -0800, Jonathan Nieder wrote:

> If someone prepares a backport of the fix for 2.13.y, would you
> like to test it?

debdiff attached.  Completely untested.
diff -u eglibc-2.13/debian/changelog eglibc-2.13/debian/changelog
--- eglibc-2.13/debian/changelog
+++ eglibc-2.13/debian/changelog
@@ -1,3 +1,11 @@
+eglibc (2.13-38+test) local; urgency=low
+
+  * patches/any/cvs-exp-rounding-mode.diff: __ieee754_exp: save and
+restore rounding mode and use round-to-nearest for all computations.
+Closes: #153022
+
+ -- Jonathan Nieder   Sun, 03 Mar 2013 23:04:24 -0800
+
 eglibc (2.13-38) unstable; urgency=low
 
   [ Adam Conrad ]
diff -u eglibc-2.13/debian/patches/series eglibc-2.13/debian/patches/series
--- eglibc-2.13/debian/patches/series
+++ eglibc-2.13/debian/patches/series
@@ -376,0 +377 @@
+any/cvs-exp-rounding-mode.diff
only in patch2:
unchanged:
--- eglibc-2.13.orig/debian/patches/any/cvs-exp-rounding-mode.diff
+++ eglibc-2.13/debian/patches/any/cvs-exp-rounding-mode.diff
@@ -0,0 +1,400 @@
+2012-03-02  Joseph Myers  
+
+   [BZ #3976]
+   * sysdeps/ieee754/dbl-64/e_exp.c: Include .
+   (__ieee754_exp): Save and restore rounding mode and use
+   round-to-nearest for all computations.
+   * math/libm-test.inc (exp_test_tonearest): New function.
+   (exp_test_towardzero): Likewise.
+   (exp_test_downward): Likewise.
+   (exp_test_upward): Likewise.
+   (main): Call the new functions.
+   * sysdeps/i386/fpu/libm-test-ulps: Update.
+   * sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
+---
+ ChangeLog |  14 +
+ math/libm-test.inc| 112 ++
+ sysdeps/i386/fpu/libm-test-ulps   |  67 +++
+ sysdeps/ieee754/dbl-64/e_exp.c|  38 -
+ sysdeps/x86_64/fpu/libm-test-ulps |  51 +
+ 5 files changed, 268 insertions(+), 14 deletions(-)
+
+diff --git a/math/libm-test.inc b/math/libm-test.inc
+index c6ed7a39..02f51f2e 100644
+--- a/math/libm-test.inc
 b/math/libm-test.inc
+@@ -2527,6 +2527,114 @@ exp_test (void)
+ 
+ 
+ static void
++exp_test_tonearest (void)
++{
++  int save_round_mode;
++  errno = 0;
++  FUNC(exp) (0);
++  if (errno == ENOSYS)
++/* Function not implemented.  */
++return;
++
++  START (exp_tonearest);
++
++  save_round_mode = fegetround ();
++
++  if (!fesetround (FE_TONEAREST))
++{
++  TEST_f_f (exp, 1, M_El);
++  TEST_f_f (exp, 2, M_E2l);
++  TEST_f_f (exp, 3, M_E3l);
++}
++
++  fesetround (save_round_mode);
++
++  END (exp_tonearest);
++}
++
++
++static void
++exp_test_towardzero (void)
++{
++  int save_round_mode;
++  errno = 0;
++  FUNC(exp) (0);
++  if (errno == ENOSYS)
++/* Function not implemented.  */
++return;
++
++  START (exp_towardzero);
++
++  save_round_mode = fegetround ();
++
++  if (!fesetround (FE_TOWARDZERO))
++{
++  TEST_f_f (exp, 1, M_El);
++  TEST_f_f (exp, 2, M_E2l);
++  TEST_f_f (exp, 3, M_E3l);
++}
++
++  fesetround (save_round_mode);
++
++  END (exp_towardzero);
++}
++
++
++static void
++exp_test_downward (void)
++{
++  int save_round_mode;
++  errno = 0;
++  FUNC(exp) (0);
++  if (errno == ENOSYS)
++/* Function not implemented.  */
++return;
++
++  START (exp_downward);
++
++  save_round_mode = fegetround ();
++
++  if (!fesetround (FE_DOWNWARD))
++{
++  TEST_f_f (exp, 1, M_El);
++  TEST_f_f (exp, 2, M_E2l);
++  TEST_f_f (exp, 3, M_E3l);
++}
++
++  fesetround (save_round_mode);
++
++  END (exp_downward);
++}
++
++
++static void
++exp_test_upward (void)
++{
++  int save_round_mode;
++  errno = 0;
++  FUNC(exp) (0);
++  if (errno == ENOSYS)
++/* Function not implemented.  */
++return;
++
++  START (exp_upward);
++
++  save_round_mode = fegetround ();
++
++  if (!fesetround (FE_UPWARD))
++{
++  TEST_f_f (exp, 1, M_El);
++  TEST_f_f (exp, 2, M_E2l);
++  TEST_f_f (exp, 3, M_E3l);
++}
++
++  fesetround (save_round_mode);
++
++  END (exp_upward);
++}
++
++
++static void
+ exp10_test (void)
+ {
+   errno = 0;
+@@ -6255,6 +6363,10 @@ main (int argc, char **argv)
+ 
+   /* Exponential and logarithmic functions:  */
+   exp_test ();
++  exp_test_tonearest ();
++  exp_test_towardzero ();
++  exp_test_downward ();
++  exp_test_upward ();
+   exp10_test ();
+   exp2_test ();
+   expm1_test ();
+diff --git a/sysdeps/i386/fpu/libm-test-ulps b/sysdeps/i386/fpu/libm-test-ulps
+index 4b1a9e73..74dbb600 100644
+--- a/sysdeps/i386/fpu/libm-test-ulps
 b/sysdeps/i386/fpu/libm-test-ulps
+@@ -453,6 +453,51 @@ Test "exp10 (3) == 1000":
+ ildouble: 8
+ ldouble: 8
+ 
++# exp_downward
++Test "exp_downward (1) == e":
++ildouble: 1
++ldouble: 1
++Test "exp_downward (2) == e^2":
++double: 1
++float: 1
++idouble: 1
++ifloat: 1
++ildouble: 2
++ldouble: 2
++Test "exp_downward (3) == e^3":
++double: 1
++float: 1
++ido

Bug#665940: Bug 637239 is still present in stable (with libc6 2.11.3-3)

[Jonathan Nieder]

unarchive 637239
forcemerge 637239 665940
quit

Hi,

In 2012, Robin Houston wrote:

> The bug reported in #637239 is still present in squeeze, though it is
> recorded
> as having been fixed in 2.11.3-1.
>
> This may be verified by running the test script at
> http://sourceware.org/bugzilla/attachment.cgi?id=5218
> and observing a segmentation fault.

Thanks for noticing, and sorry for the slow response.  If I understand
correctly, this was fixed in 2.11.3-4 by
patches/any/cvs-dlopen-tls.diff.  Please don't hesitate to write again
if it happens again.

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130304004710.GA5091@elie.Belkin

Bug#634261: [sparc] iceweasel: Bus Error in setbuf()

[Jonathan Nieder]

(culling cc list)
Hi Adrian,

John Paul Adrian Glaubitz wrote:

> [Subject: Debian #634261: Is it actually a(n RC) bug?]

Please keep in mind that these appear as emails in a crowded inbox, so
the subject line can be a good place to put valuable context.

> Mike Hommey wrote:

>> FYI, I found that it is triggered by the _IO_stdin_used symbol not
>> being exported from the binary, which happened because of a version-script
>> couple with -rdynamic. I still think there is something fishy going on
>> on the libc6 side, but not as bad as originally thought.
>
> This seems to be a known and more or less documented behavior of libc
> to determine which ABI to use for an application software, see [1].
>
> What eventually happens is an unaligned access due to the ABI
> mismatch.

I don't completely follow, so I'll just ask: do you mean that this is
a case of ABI misuse, with poor error reporting?

Can you describe what iceweasel was doing wrong?  Is this documented
so future coders know not to make the same mistake?  Is the version in
squeeze affected?  How about the version in wheezy?

Thanks and hope that helps,
Jonathan

>> [1] http://lists.gnu.org/archive/html/bug-glibc/2001-12/msg00203.html


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012113844.GA11708@elie.Belkin

Bug#690154: eglibc: FTBFS: gcc-4.4: Internal error: Segmentation fault (program as)

[Jonathan Nieder]

tags 690154 + unreproducible
# unreproducible
severity 690154 important
quit

Michael Banck wrote:
>> Lucas Nussbaum wrote:

>>> During a rebuild of all packages in *wheezy*, your package failed to
>>> build on amd64.
>>>
>>> Two notes on this bug:
>>> - the build failed twice in a row (I auto-retry failed builds)
>>> - the build did not fail with gcc 4.7 from unstable (I was doing a test
>>>   rebuild for that at the same time)
[...]
> FWIW, I cannot reproduce this in amd64/testing using sbuild, either.

Marking so.

Lucas, do you know if anyone is planning to test some time soon on a
similar setup, or should we just close this?

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121124210033.GB9219@elie.Belkin

Bug#692154: Shouldn't description mention also 3.2 kernels?

[Jonathan Nieder]

Thorsten Glaser wrote:

>>+ C3 Ezla).  
>^
>
> You introduced a pasto.

Good catch.  Patch attached.
Index: changelog
===
--- changelog   (révision 5393)
+++ changelog   (copie de travail)
@@ -1,11 +1,16 @@
 eglibc (2.13-38) UNRELEASED; urgency=low
 
+  [ Adam Conrad ]
   * debian/patches/arm/cvs-ldconfig-cache-abi.diff: Backport upstream
 patch to re-enable ldconfig cache tagging for armhf binaries again.
   * debian/patches/arm/unsubmitted-ldconfig-cache-abi.diff: Re-enable
 and adjust to account for changes in cvs-ldconfig-cache-abi.diff.
   * debian/debhelper.in/libc.preinst: Remove old ld.so.cache on upgrade.
 
+  [ Jonathan Nieder ]
+  * control.in/opt: correct misspelling of "Ezra" in descriptions of
+*-i686 variants.  Thanks to Thorsten Glaser.
+
  -- Adam Conrad   Mon, 19 Nov 2012 14:23:26 -0700
 
 eglibc (2.13-37) unstable; urgency=low
Index: control.in/opt
===
--- control.in/opt  (révision 5393)
+++ control.in/opt  (copie de travail)
@@ -14,7 +14,7 @@
  used on an i686 class CPU (check the output of `uname -m').  This includes 
  Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class CPU's
  (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, but not VIA 
- C3 Ezla).  
+ C3 Ezra).  
 
 Package: libc6-xen
 Architecture: i386
@@ -47,7 +47,7 @@
  used on an i686 class CPU (check the output of `uname -m').  This includes 
  Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class CPU's
  (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, but not VIA 
- C3 Ezla).  
+ C3 Ezra).  
 
 Package: libc0.3-i686
 Architecture: hurd-i386
@@ -65,7 +65,7 @@
  used on an i686 class CPU (check the output of `uname -m').  This includes 
  Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class CPU's
  (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, but not VIA 
- C3 Ezla).  
+ C3 Ezra).  
 
 Package: libc0.3-xen
 Architecture: hurd-i386

Bug#693848: libc6: ld.so: LD_DEBUG=libs doesn't do what help says

[Jonathan Nieder]

Samuel Bronson wrote:

> |   libsdisplay library search paths
[...]
> I expected this to list the entire library search path:
[...]
> but, as you can see, it didn't.  Is this just an unclear help message,
> or is it actually an implementation bug?

The former, I think.  Since it was introduced, LD_DEBUG=libs has only
printed information about how the location of libraries to be loaded
was determined, and when there is no RUNPATH, RPATH, or
LD_LIBRARY_PATH and the library's location is cached, that doesn't
involve printing any search paths.

Any ideas for wording it better?

Hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121121032806.GB4634@elie.Belkin

Bug#692154: Shouldn't description mention also 3.2 kernels?

[Jonathan Nieder]

severity 692154 minor
tags 692154 + patch
quit

Regid Ichira wrote:

>   Package description mentions 2.6 kernels.  These days, Debian also
> have 3.2 kernels.  Shouldn't the description mention those kernels
> too?

How about this patch?

Thanks,
Jonathan

Index: changelog
===
--- changelog   (révision 5364)
+++ changelog   (copie de travail)
@@ -1,6 +1,9 @@
 eglibc (2.13-37) UNRELEASED; urgency=low
 
-  * 
+  [ Jonathan Nieder ]
+  * control.in/opt: remove outdated reference to 2.6 kernel from
+description of i686 variant.  Thanks to Regid Ichira.  Closes:
+#692154.
 
  -- Aurelien Jarno   Fri, 26 Oct 2012 19:26:34 +0200
 
Index: control.in/opt
===
--- control.in/opt  (révision 5364)
+++ control.in/opt  (copie de travail)
@@ -11,10 +11,10 @@
  library and the standard math library, as well as many others.
  .
  This set of libraries is optimized for i686 machines, and will only be
- used if you are running a 2.6 kernel on an i686 class CPU (check the 
- output of `uname -m').  This includes Pentium Pro, Pentium II/III/IV, 
- Celeron CPU's and similar class CPU's (including clones such as AMD 
- Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezra).  
+ used on an i686 class CPU (check the output of `uname -m').  This includes 
+ Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class CPU's
+ (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, but not VIA 
+ C3 Ezla).  
 
 Package: libc6-xen
 Architecture: i386


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121103020835.GB3717@elie.Belkin

Bug#208308: *printf() and incomplete multibyte sequences may cause infinite loops in applications

[Jonathan Nieder]

found 208308 eglibc/2.13-36
tags 208308 + upstream patch
# C99 compliance
severity 208308 important
quit

Mike Hommey wrote:

> There is no "l" modifier, but still, the string goes through the
> multibyte conversion code, and fails because the string is invalid
> multibyte.

How about this patch?
Index: patches/any/cvs-vfprintf-binary.diff
===
--- patches/any/cvs-vfprintf-binary.diff(révision 0)
+++ patches/any/cvs-vfprintf-binary.diff(copie de travail)
@@ -0,0 +1,110 @@
+2012-09-28  Andreas Schwab  
+
+   [BZ #6530]
+   * stdio-common/vfprintf.c (process_string_arg): Revert
+   2000-07-22 change.
+
+2011-09-28  Jonathan Nieder  
+
+   * stdio-common/Makefile (tst-sprintf-ENV): Set environment
+   for testcase.
+   * stdio-common/tst-sprintf.c: Include 
+   (main): Test sprintf's handling of incomplete multibyte
+   characters.
+
+ stdio-common/Makefile  |  1 +
+ stdio-common/tst-sprintf.c | 13 +
+ stdio-common/vfprintf.c| 39 +++
+ 3 files changed, 17 insertions(+), 36 deletions(-)
+
+diff --git a/stdio-common/Makefile b/stdio-common/Makefile
+index 1431a211..5625bd3e 100644
+--- a/stdio-common/Makefile
 b/stdio-common/Makefile
+@@ -136,6 +136,7 @@ CFLAGS-scanf17.c = -I../libio -I../stdlib -I../wcsmbs 
-I../time -I../string \
+ 
+ # We know the test has a format string problem.
+ CFLAGS-tst-sprintf.c = -Wno-format
++tst-sprintf-ENV = LOCPATH=$(common-objpfx)localedata
+ tst-sscanf-ENV = LOCPATH=$(common-objpfx)localedata
+ tst-swprintf-ENV = LOCPATH=$(common-objpfx)localedata
+ test-vfprintf-ENV = LOCPATH=$(common-objpfx)localedata
+diff --git a/stdio-common/tst-sprintf.c b/stdio-common/tst-sprintf.c
+index bfa79c9c..42159a26 100644
+--- a/stdio-common/tst-sprintf.c
 b/stdio-common/tst-sprintf.c
+@@ -1,5 +1,6 @@
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ 
+@@ -61,5 +62,17 @@ main (void)
+   result = 1;
+ }
+ 
++  if (setlocale (LC_ALL, "de_DE.UTF-8") == NULL)
++{
++  puts ("cannot set locale");
++  result = 1;
++}
++  else if (sprintf (buf, "%.8s\n", "Foo: \277") != 7
++ || strcmp (buf, "Foo: \277\n") != 0)
++{
++  printf ("sprintf (buf, \"%%.8s\\n\", \"Foo: \\277\") produced '%s' 
output\n", buf);
++  result = 1;
++}
++
+   return result;
+ }
+diff --git a/stdio-common/vfprintf.c b/stdio-common/vfprintf.c
+index 927c0c26..25a2c5dd 100644
+--- a/stdio-common/vfprintf.c
 b/stdio-common/vfprintf.c
+@@ -1180,42 +1180,9 @@ vfprintf (FILE *s, const CHAR_T *format, va_list ap)
+   else if (!is_long && spec != L_('S')) \
+ {   \
+   if (prec != -1)   \
+-{   \
+-  /* Search for the end of the string, but don't search past\
+- the length (in bytes) specified by the precision.  Also\
+- don't use incomplete characters.  */   \
+-  if (! LOCALE_SUPPORT  \
+-||_NL_CURRENT_WORD (LC_CTYPE, _NL_CTYPE_MB_CUR_MAX) == 1) 
\
+-len = __strnlen (string, prec); \
+-  else  \
+-{   \
+-  /* In case we have a multibyte character set the  \
+- situation is more complicated.  We must not copy   \
+- bytes at the end which form an incomplete character. */\
+-  size_t ignore_size = (unsigned) prec > 1024 ? 1024 : prec;\
+-  wchar_t ignore[ignore_size];  \
+-  const char *str2 = string;\
+-  const char *strend = string + prec;   \
+-  if (strend < string)  \
+-strend = (const char *) UINTPTR_MAX;\
+-\
+-  mbstate_t ps; \
+-  memset (&ps, '\0', sizeof (ps));  \
+-\
+-  while (str2 != NULL && str2 < strend)  

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

[Jonathan Nieder]

notfound 691606 eglibc/2.13-36
tags 691606 - moreinfo
quit

Beojan Stanislaus wrote:

> strange. I upgraded again and it works now. I think it simply failed to 
> install correctly the first time around (though why aptitude didn't complain 
> about this later, I don't now.
>
> I'm closing this bug. Thank you for your help.

Thanks for checking, and sorry again for the trouble.  Hopefully it's
not a first warning of hardware failure (don't forget to check SMART
attributes and try memtest86+).

On the plus side, now you know more about what we need for future
reports. ;-)

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121027204219.GA31205@elie.Belkin

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

[Jonathan Nieder]

Beojan Stanislaus wrote:

> Although (as expected) when booting into recovery mode (the only way I can 
> login), the syslog output appears on the screen during boot.

Ok, perfect.  In recovery mode, could you please run

set -x
. /etc/default/locale
dmesg

and attach the output?

We need to know the exact output, not an approximation.  Thanks again
for your patience.


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121027195944.GA30714@elie.Belkin

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

[Jonathan Nieder]

Beojan Stanislaus wrote:
> On Saturday 27 October 2012 11:56:26 Jonathan Nieder wrote:

>> Could you try:
>>
>>  set -x
>>  . /etc/default/locales; # or whatever file reproduces this
>>
>> and then also attach full "dmesg" output?
[...]
> Unfortunately not, since, as this bug makes my system unusable, I have 
> downgraded the locales package alone to 2.13-35 from wheezy.

Perhaps in a chroot or in the live environment from a live cd?
Without these logs, it's hard to see how to track this down further.

> 2.13-36 makes the system fail to boot, as I mentioned in the original report, 
> since the scripts calling . /etc/default/locales; are the init scripts in 
> /etc/init.d. As a result I am unable to test your suggestion.

Another alternative would be to take a photograph of the screen when
this happens.  How do you know that /etc/default/locales is the cause?
By the way, do you mean /etc/default/locales or /etc/default/locale?

> However, I can add that calling update-locale with the faulty package causes 
> the same floating point exception message.

Thanks and hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121027194210.GA30633@elie.Belkin

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

[Jonathan Nieder]

Beojan Stanislaus wrote:

> locale file attached.
[...]
> #  File generated by update-locale
> LANG="en_GB.UTF-8"
> LANGUAGE="en_GB:en"

Ok, thanks.  I don't see anything objectionable there, so the problem
has to be somewhere else.

Could you try:

 set -x
 . /etc/default/locales; # or whatever file reproduces this

and then also attach full "dmesg" output?

Sorry for the trouble, and hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121027185626.GC28633@elie.Belkin

Bug#691606: [locales] Causes system to fail to boot with floating point exceptions

[Jonathan Nieder]

tags 691606 + moreinfo
# machine-specific
severity 691606 important
quit

Hi,

Beojan Stanislaus wrote:

> This version of locales causes any script that includes the line 
>   . /etc/default/locales
>
> to exit with a floating point exception.

I don't have that file.  I do have

$ grep . /etc/default/locale 
#  File generated by update-locale
#LANG=de_DE.UTF-8
#LANGUAGE=en:de

but I suspect you're looking at a different file.  Could you attach it?

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121027174641.GA28633@elie.Belkin

Bug#650234: Use chroot's ld.so to do loading?

[Jonathan Nieder]

unmerge 626482
reassign 650234 fakechroot 2.15-1
severity 650234 important
tags 650234 + upstream
quit

Elliott Mitchell wrote:

> user@host:/$ ls
> Segmentation fault
> user@host:/$ /lib/ld-linux.so.2 ls
> ls: error while loading shared libraries: ls: cannot open shared object file: 
> No such file or directory
> user@host:/$ /lib/ld-linux.so.2 /bin/ls
> bin   debootstrap  etc lib  proc  sbin sys  usr
[...]
> So, something along these lines is possible.

Thanks.  Indeed, ideally fakechroot's execve should look up the
interpreter filename from the ELF .interp section, map it according to
the faked chroot, and set argv[0].  The hard part is the ELF parsing.

Hints for inspiration[1]:

  git://github.com/NixOS/patchelf.git
  https://fedorahosted.org/elfutils/

Doable, though it seems a little too much like work for me to actually
do it. ;-)  Reassigning because I can't imagine glibc changing its
compatibility requirements any time soon.

Hope that helps,
Jonathan

[1] some pseudocode to experiment with for your amusement:

diff --git i/src/execve.c w/src/execve.c
index 60351177..70d0a9ea 100644
--- i/src/execve.c
+++ w/src/execve.c
@@ -71,6 +71,25 @@ static int try_cmd_subst (char * env, const char * filename, 
char * cmd_subst)
 return 0;
 }
 
+static int get_elf_interp(const char * filename, char * buf, size_t buflen)
+{
+int num_sections = num_sections();  /* header->e_shnum */
+int i;
+
+for (i = 0; i < num_sections; i++) {
+string section_name = section_names + section_header[i].sh_name;
+if (section_name == ".interp")  /* found it! */
+break;
+}
+if (i == num_sections)
+return -1;
+
+// found .interp section
+size_t offset = section_hdr.sh_offset;
+size_t size = section_hdr.sh_size;
+...
+}
+
 
 wrapper(execve, int, (const char * filename, char * const argv [], char * 
const envp []))
 {
@@ -195,8 +214,11 @@ wrapper(execve, int, (const char * filename, char * const 
argv [], char * const
 }
 
 /* No hashbang in argv */
-if (hashbang[0] != '#' || hashbang[1] != '!')
-return nextcall(execve)(filename, argv, newenvp);
+if (hashbang[0] != '#' || hashbang[1] != '!') {
+if (get_elf_interp(filename, hashbang + 2, sizeof(hashbang) - 3))
+return nextcall(execve)(filename, argv, newenvp);
+i = strlen(hashbang);
+}
 
 /* For hashbang we must fix argv[0] */
 hashbang[i] = hashbang[i+1] = 0;


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121024073255.GA9820@elie.Belkin

Bug#684889: Confirmed, but FTBFS with patch (Re: eglibc: CVE-2012-3480)

[Jonathan Nieder]

Hi Bas,

Bas Wijnen wrote:

> Encountered regressions that don't match expected failures:
> tst-cputimer1.out, Error 1
> make: *** [/tmp/eglibc-2.13/stamp-dir/check_i686] Fout 1

Yeah, I don't think this is due to the patch.

It's been mentioned in various places: e.g., [1] [2]

I can't find a report of the tst-cputimer1 failures at
, so if you have time to reproduce it
with glibc trunk[3] and file one (feel free to cc me) then that would
be great.

Thanks,
Jonathan

[1] http://sourceware.org/glibc/wiki/Release/2.16?action=diff&rev1=25&rev2=26
(2012-06-19)
[2] http://www.linuxfromscratch.org/lfs/view/stable/chapter06/glibc.html
(r9956 2012-08-22, regarding glibc 2.16)
[3] git://sourceware.org/git/glibc.git


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121014121648.GA18301@elie.Belkin

Bug#690154: eglibc: FTBFS: gcc-4.4: Internal error: Segmentation fault (program as)

[Jonathan Nieder]

Hi Lucas,

Lucas Nussbaum wrote:

> During a rebuild of all packages in *wheezy*, your package failed to
> build on amd64.
>
> Two notes on this bug:
> - the build failed twice in a row (I auto-retry failed builds)
> - the build did not fail with gcc 4.7 from unstable (I was doing a test
>   rebuild for that at the same time)
[...]
>> gcc-4.4 -m32 ../sysdeps/i386/fpu/k_rem_pio2l.c -c [...]
>> gcc-4.4: Internal error: Segmentation fault (program as)

I am not able to reproduce this with gcc-4.4 4.4.7-2 and binutils 2.22-7.1
on amd64, building with

debuild -I -i -b

Any hints?

If you can reproduce this, would it be possible to get the input files
and "as" command line that triggers the segfault as described in
/usr/share/bug/binutils/presubj?

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121011153205.GA28697@elie.Belkin

Bug#689932: Please define sized int{8,16,32,64}_t types portably even for GCC

[Jonathan Nieder]

Josh Triplett wrote:
> On Sun, Oct 07, 2012 at 04:52:30PM -0700, Jonathan Nieder wrote:

>> Which compiler are you using?  Is its identifying itself as gcc >= 2.7
>> intentional?
>
> c2hs, which uses GCC's preprocessor.

Independently of this request, that seems like a bug.  Perhaps it
could be convinced to pass -U__GNUC__ -U__GNUC_MINOR__
-U__GNUC_PATCHLEVEL__ to cpp.

>   And many other non-GCC compilers
> identify themselves as GCC as well,

Many do, but I didn't know of any that specified a specific version
until today.

Thanks again,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121008021031.GA8041@elie.Belkin

Bug#689932: Please define sized int{8,16,32,64}_t types portably even for GCC

[Jonathan Nieder]

Hi Josh,

Josh Triplett wrote:

> However, for compilers that identify themselves as GCC (which includes
> many non-GCC compilers), sys/types.h does this instead:
>
> # define __intN_t(N, MODE) \
>   typedef int int##N##_t __attribute__ ((__mode__ (MODE)))

The condition used is

#if !__GNUC_PREREQ (2, 7)

Which compiler are you using?  Is its identifying itself as gcc >= 2.7
intentional?

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121007235230.GB31925@elie.Belkin

Bug#555168: Request for wheezy-ignore tag: bug#555168 (glibc locale files with license not permitting modification)

[Jonathan Nieder]

Julien Cristau wrote:

>   Hopefully it won't take too much longer to
> sort out, but I don't think there's a point delaying the release (or
> deleting existing locale data from the distro) while there's hope of a
> resolution.

Thanks for looking it over.  Makes sense.

Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120917015520.GD3050@elie.Belkin

Bug#682678: /usr/include/features.h referes to bits/predefs.h, but no "bits" link or dir in /usr/include

[Jonathan Nieder]

# affects many libraries, not just libc
reassign 682678 general
merge 637232 682678
quit

Hi Alex,

Alex Adam wrote:

> I've tried to build GCC-4.6.2 on my system from sources.
> I've got compilation failed with the following error message:
> In file included from /usr/include/stdio.h:28:0,
>  from
> /home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../gcc/tsystem.h:87,
>  from
> /home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../gcc/libgcc2.c:29:
> /usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or 
> directory

This is http://gcc.gnu.org/PR53468

As mentioned in /usr/share/doc/libc6/NEWS.Debian.gz, using

LIBRARY_PATH=/usr/lib/$(gcc -print-multiarch)
CPATH=/usr/include/$(gcc -print-multiarch)
export LIBRARY_PATH CPATH

before the usual

./configure 
make

is supposed to work around it.  Does it work for you?

Curious,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724163848.GC2939@burratino

Bug#555168: Unclear license situation for (e)glibc locales provided by you

[Jonathan Nieder]

Raphael Finkel wrote:

> Helge,
>
> I would be glad to relicense this work in whatever way will give it the
> most distribution.  I don't want to restrict it, but I would like my
> name associated with it.

Does that mean something like

 % This file has been put in the public domain.
 % You can do whatever you want with this file.
 %
 % 2003-08-16: corrections from Raphael Finkel 
 %

for locales/yi_US would be okay with you if Pablo Saratxaga is ok with it?

Thanks,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120702052741.GA2986@burratino

Bug#679172: ls[8213]: segfault in libc-2.11.3.so

[Jonathan Nieder]

Hi Axel,

a...@users.sourceforge.net wrote:

> Just found this in /var/log/kern.log and /var/log/messages:
>
> ls[8213]: segfault at 1ebbc787 ip b769aa53 sp bffcbc14 error 4 in 
> libc-2.11.3.so[b7626000+14]

If anything, this would be a symptom of memory corruption or a bug in
"ls".  Can you reproduce it?

Curious,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120626205041.GB5200@burratino

Bug#673596: NPTL not properly cleaning up threads on SMP systems?

[Jonathan Nieder]

# submitters and upstream can reproduce it
tags 673596 - unreproducible
clone 673596 -1
retitle -1 pthread_join returns before child thread has been reaped
forwarded -1 http://thread.gmane.org/gmane.comp.lib.glibc.user/1356/focus=1359
# difficult
severity -1 wishlist
forwarded 673596 http://thread.gmane.org/gmane.comp.lib.glibc.user/1356
block 673596 by -1
tags 673596 + patch
quit

Thibaut Girka wrote[1]:

> I've recently tried to build eglibc from Debian's source package,
> but it aborted because of a failed test[1]: nptl/tst-eintr1.
> This test failed because one of the pthread_create calls returned EAGAIN.
> Indeed, after some time, instead of 12~23 threads,
> “grep Threads /proc/$PID/status” reveals much more threads (up to several 
> thousands).

Siddhesh Poyarekar explained[2]:

> On a serious note, I see this all the time on my tests runs and it is
> in fact a kernel issue. The problem here is that the kernel needs to
> signal the joining thread before it exits and the time taken from that
> point to actual freeing of task resources seems to be longer than the
> time it takes for the process to spawn another thread after joining
> and for that thread to return.
>
> A very simple way to eliminate this is to introduce a very small
> usleep within the thread function.

Debian eglibc maintainers: how about this patch (untested)?

It modifies tst-eintr1 to try again instead of failing when hitting
the race.

if (e == EAGAIN)
  continue;

An alternative would be to mark tst-eintr1 as an expected failure, but
I prefer this workaround since it means other kinds of failure in the
test can still be caught.

It is not clear to me whether the underlying problem is a bug in
pthread_join() or just a quality of implementation issue (in which
case it would also be a bug in the testsuite).  POSIX defines
pthread_join() as waiting for the target thread's termination:

The pthread_join() function shall suspend execution of the
calling thread until the target thread terminates, unless the
target thread has already terminated. 

It seems to imply that joined threads do not count towards an
implementation's limits:

It is unspecified whether a thread that has exited but remains
unjoined counts against {PTHREAD_THREADS_MAX}.

However, the (non-normative) rationale suggests that pthread_join()
can be emulated through a procedure that would be subject to the same
race that breaks tst-eintr1:

It is true that a programmer could simulate this function if it
were not provided by passing extra state as part of the argument
to the start_routine().  The terminating thread would set a flag
to indicate termination and broadcast a condition that is part
of that state; a joining thread would wait on that condition
variable. 
[...]
Thus, while not a primitive, including pthread_join() in this
volume of POSIX.1-2008 was considered valuable.

Meh.

Hope that helps,
Jonathan

[1] http://thread.gmane.org/gmane.comp.lib.glibc.user/1356
[2] http://thread.gmane.org/gmane.comp.lib.glibc.user/1356/focus=1358
Index: debian/changelog
===
--- debian/changelog(revision 5284)
+++ debian/changelog(working copy)
@@ -11,6 +11,11 @@
   * patches/hurd-i386/libpthread_nort.diff: Add patch to revert upstream librt
 usage.
 
+  [ Jonathan Nieder ]
+  * patches/any/unsubmitted-tst-eintr1-eagain.diff: new patch to work around a
+race that lets pthread_create hit resource limits when the kernel takes
+too long to clean up after joined threads.  Closes: #673596.
+
  -- Aurelien Jarno   Sun, 03 Jun 2012 22:51:53 +0200
 
 eglibc (2.13-33) unstable; urgency=medium
Index: debian/patches/any/unsubmitted-tst-eintr1-eagain.diff
===
--- debian/patches/any/unsubmitted-tst-eintr1-eagain.diff   (revision 0)
+++ debian/patches/any/unsubmitted-tst-eintr1-eagain.diff   (working copy)
@@ -0,0 +1,25 @@
+2012-06-06  Jonathan Nieder  
+
+   * nptl/tst-eintr1.c (tf1): Tolerate EAGAIN from pthread_create.
+
+---
+
+--- a/nptl/tst-eintr1.c
 b/nptl/tst-eintr1.c
+@@ -49,6 +49,16 @@
+ puts ("pthread_create returned EINTR");
+ exit (1);
+   }
++if (e == EAGAIN)
++  {
++/* The kernel might not have processed the last few
++   pthread_join()s yet.  Tolerate that, but record the
++   event in test output so attentive people reading
++   logs can notice if pthread_join() stops working
++   altogether.  */
++write (STDOUT_FILENO, "!", 1);
++continue;
++  }
+ 
+ char buf[100];
+ printf ("tf1: pthread_create failed: %s\n",
Index: debian/patches/series
==

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

tags 673596 + upstream
quit

Thibaut Girka wrote:

> dlfcn/bug-atexit3 is the first to fail (fails to load libstdc++.so.6).

Oh, right.  glibc doesn't know to look to /lib/$(gcc -print-multiarch)
for libraries, so I usually copy libstdc++.so.6 and libgcc_s.so.1 to
the build tree by hand so the test suite can use them.  There's
probably a more elegant way.

[...]
> Yeah, running it using the newly-built glibc reproduces the bug.
>
> (I ran it like that:
>  ./elf/ld-linux.so.2 --library-path .:elf:nptl /home/thib/tmp/a.out
> )
>
> In addition, I've been watching /proc/$PID/status to see how the program 
> behaves.
> Most of the time, the number of threads stays in 2 ~ NB_THREADS, but at some 
> point in time,
> it may increase to hundreds, or even thousands of threads.

Perfect --- looks like it's not a Debian-specific bug and the mass of
glibc hackers at large can be brought to bear on it, too.

Please contact libc-h...@sourceware.org[1] with your testcase and a
summary of the symptoms and how you ran into it to get help tracking
down the cause.

Thanks again for narrowing this down this far.  Hopefully we can find
the culprit soon.

Good luck,
Jonathan

[1] Traffic is about 2 messages per day.  I don't remember whether it
is subscribers-only.  It's probably safest to subscribe (with or
without mail delivery) to be sure mail doesn't get stuck in a
moderation queue: http://www.gnu.org/software/libc/development.html



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120531210535.GB27332@burratino

Bug#674412: tcc: undefined symbol '__builtin_expect' on pthread_cleanup_push() call

[Jonathan Nieder]

tags 674412 + upstream
notforwarded 674412
quit

Hi,

Thomas Preud'homme wrote:
> Le jeudi 24 mai 2012 14:47:39, vous avez écrit :

>> $ tcc -Wall -Wextra thread.c -pthread
>> thread.c:10: warning: implicit declaration of function '__builtin_expect'
>> tcc: error: undefined symbol '__builtin_expect'
[...]
> In pthread.h, pthread_cleanup_push is defined around line 650 in the 
> following 
> way when __GNUC__ is not defined (the case for tcc for example):
>
> # define pthread_cleanup_push(routine, arg) \
>   do {
> \
> __pthread_unwind_buf_t __cancel_buf;  
> \
> void (*__cancel_routine) (void *) = (routine);
> \
> void *__cancel_arg = (arg);   
> \
> int __not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *) 
> \
> __cancel_buf.__cancel_jmp_buf, 0);
> \
> if (__builtin_expect (__not_first_call, 0))   
> \
>   {   
> \
[...]
> This makes use of __builtin_expect which should not be assume to exist.

Good catch, thanks.  Looks like an old one.

This doesn't seem to have been fixed upstream, so please report this
to http://sourceware.org/bugzilla, product glibc, component nptl, and
let us know the bug number so we can track it.

Hope that helps,
Jonathan



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120531151048.GB25331@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

Thibaut Girka wrote:

> I couldn't reproduce this because of other failed tests.

Which test?  If you use LD_LIBRARY_PATH to use the newly built libc
and libpthread, does your testcase still reproduce the bug?  (It
should be possible to see if the intended libs are being picked up
with "ldd".)



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120530202259.GL3908@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

Jonathan Nieder wrote:

>  # configure
>  cd glibc
>  mkdir BUILD
>  ../configure --prefix=$HOME/opt/glibc

Whoops, left out a second "cd".  I meant:

mkdir glibc/BUILD
cd glibc/BUILD
../configure --prefix=$HOME/opt/glibc

Sorry for the confusion.
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120530073102.GC19114@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

Thibaut Girka wrote:

> Well, no, after a quick inspection, it appears the test behaves correctly.
> Then, I have no idea why it would fail.

Thanks.  Ok, a new test to try:

 # get the source:
 git clone git://sourceware.org/git/glibc.git

 # configure
 cd glibc
 mkdir BUILD
 ../configure --prefix=$HOME/opt/glibc

 # build - this takes a while
 make

 # test
 make check

If it reproduces the problem, then that would mean this is not Debian-
specific, so please write to libc-h...@sourceware.org in that case to
request advice[1].  (If we are lucky, someone might recognize the bug or
know of some command like "strace -f" or patch that could help track
it down.)

[...]
> Sorry for wasting your time,

No --- not at all.  By now I think we understand better how much the
result doesn't make sense. :)

Jonathan

[1] http://www.gnu.org/software/libc/development.html



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120530072200.GB19114@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

Hi Thibaut,

Thibaut Girka wrote:

> I've been bitten by this bug too, and here is what I've gathered:
>
> tst-eintr1 spawns threads continuously, without joining them, until it
> receives a SIGALRM.

Thanks for the analysis.

If I am reading correctly, tst-eintr1 tries to spawn 11 child threads,
one of which sends SIGUSR1 to other threads in a loop with a handler
that writes '.' and the other 10 of which spawn and join a child
repeatedly in a loop.  At any given moment, there would be somewhere
in the range of 12 to 22 active threads (1 x driver + 1 x signal
source + 10 x tf1 + 0-10 x tf2).

Have you noticed the test behaving differently?  Maybe when
pthread_join returns the process is still around?  How do you know
there are extra unjoined threads?

Curious,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120530030742.GB3467@burratino

Bug#674917: libc6-dev: mblen is erroneously marked warn_unused_result

[Jonathan Nieder]

forwarded 674917 http://sourceware.org/PR14176
quit

Antti-Juhani Kaijanaho wrote:

> However, I've done what you asked.
> http://sourceware.org/bugzilla/show_bug.cgi?id=14176

Thanks much.

Kind regards,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120529193638.GA21450@burratino

Bug#674917: libc6-dev: mblen is erroneously marked warn_unused_result

[Jonathan Nieder]

tags 674917 + upstream patch
quit

Hi,

Antti-Juhani Kaijanaho wrote:

> However, so far as I can see, ignoring the return value of mblen is never a
> security problem and is sometimes appropriate (the first call to the function
> is often mblen(NULL, 0), the result value of which is usually of no interest).

This doesn't seem to be fixed upstream, so please report it to
, product glibc, component libc and
let us know the bug number so we can track it.

> (Debian's use of -D_FORTIFY_SOURCE=2 and the common policy of using -Werror
> together make this a noncosmetic issue.)

Using -Werror in contexts other than private development where you
control the toolchain and can easily suppress known warnings is not
very wise.

Thanks and hope that helps,
Jonathan

* stdlib/stdlib.h (mblen): Remove __wur.
It is not necessarily an error to ignore the return value from
mblen(NULL, 0) which resets the shift state.

diff --git i/stdlib/stdlib.h w/stdlib/stdlib.h
index f652eda3..f14ec0e3 100644
--- i/stdlib/stdlib.h
+++ w/stdlib/stdlib.h
@@ -859,7 +859,7 @@ extern int qfcvt_r (long double __value, int __ndigit,
 __BEGIN_NAMESPACE_STD
 /* Return the length of the multibyte character
in S, which is no longer than N.  */
-extern int mblen (const char *__s, size_t __n) __THROW __wur;
+extern int mblen (const char *__s, size_t __n) __THROW;
 /* Return the length of the given multibyte character,
putting its `wchar_t' representation in *PWC.  */
 extern int mbtowc (wchar_t *__restrict __pwc,



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120529163603.GB17455@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

retitle 673596 libc6: tst-eintr1 fails ("tf1: pthread_create failed: Resource 
temporarily unavailable")
quit

Philip Ashmore wrote:

> ...and here they are< $ ldd build-tree/amd64-libc/nptl/tst-eintr1
> linux-vdso.so.1 =>   (0x7fff481ff000)
> libpthread.so.0 =>  /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7f6577c99000)
> libc.so.6 =>  /lib/x86_64-linux-gnu/libc.so.6 (0x7f6577912000)
> /lib64/ld-linux-x86-64.so.2 (0x7f6577ecd000)
> contact@debian:~/eglibc-2.13$ build-tree/amd64-libc/nptl/tst-eintr1
> .tf1:
>  pthread_create failed: Resource temporarily unavailable
> .Expected signal 'Alarm clock' from child, got none
> EOF

Great, thanks.  That shows that the installed libc exhibits the same
problem as the just-built one.

Is there a 32-bit copy of tst-eintr1 in the build tree you could test
libc6-i386 with as well?



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120523153608.GE21608@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

Jonathan Nieder wrote:

> Do you have access to another machine you could try to reproduce the
> problem on?

Actually, before then: could you please run the test I outlined before?

That is:

 1. Find tst-eintr1.  It should be somewhere like
build-tree/amd64-libc/nptl/tst-eintr1

 2. Run it.  (Like this:

$ ldd build-tree/amd64-libc/nptl/tst-eintr1
$ build-tree/amd64-libc/nptl/tst-eintr1

)

Some variations on the theme would be to try the 32-bit version, too,
and to try it with LD_LIBRARY_PATH set to use libpthread from
build-tree/amd64-libc/nptl, but those can come later.

Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120523151851.GD21608@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

Philip Ashmore wrote:

> It looks like you're building on i386 - the bug report is for amd64.

My bad --- sorry about that.

> If someone could tell me the steps, I could provide you with the automated 
> install script
> to set up Debian Wheezy in VMware so it's the same as mine, allowing others to
> reproduce the problem.

I'm not going to install VMware to work on this, but maybe someone
else will.

Do you have access to another machine you could try to reproduce the
problem on?

Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120523150233.GB21608@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

severity 673596 important
quit

Hi Philip,

Philip Ashmore wrote:

> Should I attach /var/log/dmesg?

Unless you've been running into other problems, I wouldn't bother.

I doubt this problem is CPU-specific, though of course I could be
wrong.  How reproducible is the test failure?  You can run tests again
by removing stamp-dir/check_* and running "debian/rules build" again,
or run a single test explicitly by running

build-tree/i386-i686/elf/ld-linux.so.2 \
--library-path $(pwd)/build-tree/i386-i686:\
$(pwd)/build-tree/i386-i686/math:\
$(pwd)/build-tree/i386-i686/elf:\
$(pwd)/build-tree/i386-i686/dlfcn:\
$(pwd)/build-tree/i386-i686/nss:\
$(pwd)/build-tree/i386-i686/nis:\
$(pwd)/build-tree/i386-i686/rt:\
$(pwd)/build-tree/i386-i686/resolv:\
$(pwd)/build-tree/i386-i686/crypt:\
$(pwd)/build-tree/i386-i686/nptl \
build-tree/i386-i686/nptl/tst-eintr1

(command retrieved with "make -n".  The corresponding code is in
Makeconfig.)

Set the LD_TRACE_LOADED_OBJECTS envvar to 1 if you want to make sure
this command is testing the appropriate version of libc.  You can also
experiment by checking whether tst-eintr1 works as it should with the
system copy of libc.

I'm lowering the severity because I wasn't able to trigger trouble
building eglibc on this machine (Thinkpad G41, Pentium 4, kernel from
linux-next) so this bug is still missing a reproduction recipe.

Hope that helps,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012053232.GA23178@burratino

Bug#673933: eglibc: FTBFS with patch from experimental (hurd-i386/libpthread_clean.diff patches the wrong file)

[Jonathan Nieder]

tags 673933 + patch
quit

Jonathan Nieder wrote:

> The attached patch seems to fix it.

Here's the same as a patch against the repo on svn.debian.org.
Index: debian/changelog
===
--- debian/changelog(revision 5255)
+++ debian/changelog(working copy)
@@ -25,6 +25,12 @@
 sendto() calls with NULL addr.
   * control/{main,libc}: Remove libpthread-stubs-dev dependency on hurd-i386.
 
+  [ Jonathan Nieder ]
+  * debian/patches/hurd-i386/libpthread_{clean.diff,librt-link.diff}:
+correct filenames on "diff --git" lines.  Otherwise, very recent
+(post-2.6.1) versions of GNU patch fail to apply the patches.
+Closes: #673933.
+
  -- Clint Adams   Fri, 04 May 2012 23:39:00 -0400
 
 eglibc (2.13-32) unstable; urgency=medium
Index: debian/patches/hurd-i386/libpthread_librt-link.diff
===
--- debian/patches/hurd-i386/libpthread_librt-link.diff (revision 5255)
+++ debian/patches/hurd-i386/libpthread_librt-link.diff (working copy)
@@ -1,4 +1,4 @@
-diff --git a/Makefile b/Makefile
+diff --git a/libpthread/Makefile b/libpthread/Makefile
 index e8c77e3..4112694 100644
 --- a/libpthread/Makefile
 +++ b/libpthread/Makefile
Index: debian/patches/hurd-i386/libpthread_clean.diff
===
--- debian/patches/hurd-i386/libpthread_clean.diff  (revision 5255)
+++ debian/patches/hurd-i386/libpthread_clean.diff  (working copy)
@@ -1,7 +1,7 @@
 These come from the l4 implementation and come in the way of the glibc
 Makefiles, drop them.
 
-diff --git a/signal/README b/signal/README
+diff --git a/libpthread/signal/README b/libpthread/signal/README
 deleted file mode 100644
 index 5487e2e..000
 --- a/libpthread/signal/README
@@ -11,7 +11,7 @@
 -for operating systems where signals are managed at user-level.  It is
 -up to the run-time to catch the signals and forward them to the
 -implementation via, e.g., the pthread_kill_info_np call.
-diff --git a/signal/TODO b/signal/TODO
+diff --git a/libpthread/signal/TODO b/libpthread/signal/TODO
 deleted file mode 100644
 index 1148abb..000
 --- a/libpthread/signal/TODO
@@ -47,7 +47,7 @@
 -
 -Implement sigtimedwait, sigqueue.
 \ No newline at end of file
-diff --git a/signal/kill.c b/signal/kill.c
+diff --git a/libpthread/signal/kill.c b/libpthread/signal/kill.c
 deleted file mode 100644
 index 27c9c32..000
 --- a/libpthread/signal/kill.c
@@ -123,7 +123,7 @@
 -  return pthread_kill (pthread_self (), signo);
 -}
 -
-diff --git a/signal/pt-kill-siginfo-np.c b/signal/pt-kill-siginfo-np.c
+diff --git a/libpthread/signal/pt-kill-siginfo-np.c 
b/libpthread/signal/pt-kill-siginfo-np.c
 deleted file mode 100644
 index 9bdf6cc..000
 --- a/libpthread/signal/pt-kill-siginfo-np.c
@@ -217,7 +217,7 @@
 -  return 0;
 -}
 -
-diff --git a/signal/sig-internal.c b/signal/sig-internal.c
+diff --git a/libpthread/signal/sig-internal.c 
b/libpthread/signal/sig-internal.c
 deleted file mode 100644
 index f73f38b..000
 --- a/libpthread/signal/sig-internal.c
@@ -249,7 +249,7 @@
 -
 -sigset_t process_pending;
 -siginfo_t process_pending_info[NSIG];
-diff --git a/signal/sig-internal.h b/signal/sig-internal.h
+diff --git a/libpthread/signal/sig-internal.h 
b/libpthread/signal/sig-internal.h
 deleted file mode 100644
 index 6c86c79..000
 --- a/libpthread/signal/sig-internal.h
@@ -432,7 +432,7 @@
 -}
 -
 -#endif
-diff --git a/signal/sigaction.c b/signal/sigaction.c
+diff --git a/libpthread/signal/sigaction.c b/libpthread/signal/sigaction.c
 deleted file mode 100644
 index 0126c99..000
 --- a/libpthread/signal/sigaction.c
@@ -510,7 +510,7 @@
 -  return 0;
 -}
 -
-diff --git a/signal/sigaltstack.c b/signal/sigaltstack.c
+diff --git a/libpthread/signal/sigaltstack.c b/libpthread/signal/sigaltstack.c
 deleted file mode 100644
 index 8334811..000
 --- a/libpthread/signal/sigaltstack.c
@@ -585,7 +585,7 @@
 -}
 -  return 0;
 -}
-diff --git a/signal/signal-dispatch.c b/signal/signal-dispatch.c
+diff --git a/libpthread/signal/signal-dispatch.c 
b/libpthread/signal/signal-dispatch.c
 deleted file mode 100644
 index 40440b7..000
 --- a/libpthread/signal/signal-dispatch.c
@@ -708,7 +708,7 @@
 -
 -  SIGNAL_DISPATCH_EXIT;
 -}
-diff --git a/signal/signal.h b/signal/signal.h
+diff --git a/libpthread/signal/signal.h b/libpthread/signal/signal.h
 deleted file mode 100644
 index a33d995..000
 --- a/libpthread/signal/signal.h
@@ -989,7 +989,7 @@
 -const struct timespec *restrict timespec);
 -
 -#endif
-diff --git a/signal/sigpending.c b/signal/sigpending.c
+diff --git a/libpthread/signal/sigpending.c b/libpthread/signal/sigpending.c
 deleted file mode 100644
 index 609b55d..000
 --- a/libpthread/signal/sigpending.c
@@ -1033,7 +1033,7 @@
 -
 -  return 0;
 -}
-diff --git a/signal/sigsuspend.c b/signal/sigsuspend.c
+diff --git a/libpthread/signal/sigsusp

Bug#673933: eglibc: FTBFS with patch from experimental (hurd-i386/libpthread_clean.diff patches the wrong file)

[Jonathan Nieder]

Source: eglibc
Version: 2.13-32
Tags: experimental
Justification: will ftbfs with GNU patch (>= 2.6.2)
X-Debbugs-Cc: pa...@packages.debian.org

Hi,

Philip Ashmore wrote[1]:

> The wheezy installation failed to build eglibc-2.13-32 with the
> following errors

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

Philip Ashmore wrote:

> .tf1: pthread_create failed: Resource temporarily unavailable
> tf1: pthread_create failed: Resource temporarily unavailable

That's EAGAIN, which usually would mean some resource limit has been
hit (or an out-of-memory condition).  Does one of

ulimit -a
cat /proc/sys/kernel/threads-max

reveal anything interesting?

[...]
> Also , tst-writev.out contains < writev() return value: 2147479552 != EXPECTED: 2147483648
> EOF

Yeah, that's a known bug ().

> Sorry if I was cryptic/terse.

No problem, and thanks for testing.

Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520031025.GE32635@burratino

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)

[Jonathan Nieder]

Hi Philip,

Philip Ashmore wrote:

> annexc.out, Error 1 (ignored)
> tst-eintr1.out, Error 1
> tst-writev.out, Error 1
> ***
> Encountered regressions that don't match expected failures:
> tst-eintr1.out, Error 1

What does the tst-eintr1.out file say?

Curious,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520020248.GB32635@burratino

Bug#673339: [locales] es_MX has wrong decimal_point and thousands_sep

[Jonathan Nieder]

severity 673339 important
quit

Carlos C Soto wrote:

> Severity: critical

This is not critical.

[...]
> The locales for es_MX in decimal_point and thousands_sep should be
> the same as en_US:
[...]
> This command has inverted the "." and the ","

Thanks for reporting,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120517223605.GC2967@burratino

Bug#671709: libc6-i386: libc6 no valid name for dpkg as multiarch install on amd64 - error code (2)

[Jonathan Nieder]

reassign 671709 apt 0.8.15.10
forcemerge 665727 671709
quit

Hi Thomas,

thomas wrote:

> Hole:1 http://debian.tu-bs.de/debian/ testing/main libc6-i686 i386 2.13-32 
> [1.242 kB]
> Es wurden 1.242 kB in 1 s geholt (1.062 kB/s)
> Lese Changelogs... Fertig
> dpkg: Fehler: --configure benötigt einen gültigen Paketnamen. »libc6« ist 
> kein solcher; mehrdeutiger Paketname »libc6« mit mehr als einer installierten 
> Instanz

I suspect this is fixed by apt 0.8.16 and newer.  Can you confirm?

Thanks,
Jonathan



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120506083355.GA26621@burratino

Bug#564874: manpages: Please ship ld.so manpage

[Jonathan Nieder]

reassign 564874 manpages 3.23-1
quit

Simon Paillard wrote:

> I concur, but we need agreement of libc-bin maintainers.

Reassigning to manpages, since this couldn't be fixed by a change in
eglibc alone (or in other words: to unconfuse debbugs[1]).  If you
think the page is ready already, then please do coordinate with the
libc maintainers to make the appropriate packaging changes.

[1] see http://www.debian.org/Bugs/server-control#reassign



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429180423.GA26723@burratino

Bug#564874: manpages: Please ship ld.so manpage

[Jonathan Nieder]

Michael Kerrisk wrote:

> For info: Jonathan Neider, CCed was looking at integrating those
> pieces of the Debian libc-bin page that were missing from the upstream
> man-pages ld.so.8 page. We did upstream one piece already, but I'm not
> sure what Jonathan's current plans are for further work.

Looking for a spare moment, but if someone else wants to pick up the
slack I won't mind at all.

Thanks,
Jonathan

http://thread.gmane.org/gmane.linux.man/2377



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429175913.GA26653@burratino

Re: [Fwd: Re: eglibc 2.14 for wheezy?]

[Jonathan Nieder]

Hi,

Svante Signell wrote:

> Hello, I was recommended to forward my question here. What is the
> current plan? The wheezy release is not too far away.

(Disclaimer: I am not an eglibc maintainer.)  It is rather late to get
eglibc 2.14 into wheezy, and my best guess is that it probably won't
happen.  If someone works very hard at making sure that branch works
well and that bugs in other packages that use it are addressed, it
might be possible, though.

Are there particular fixes from 2.14 you would like to make sure make
it into wheezy?

Hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120414231944.GA5489@burratino

Bug#552561: please provide en_CH locale

[Jonathan Nieder]

Hi,

wiekalth...@gmx.de wrote:

> [Subject: What is the status?]

Please keep in mind that these appear as emails in a crowded inbox, so
the subject line can be a good place to put valuable context.

> I have similar needs as Martin. Want my system to speak English with
> whatever local flavor I like.  It would be great, if this could be
> set at installation and afterwards.

For afterwards: I believe something like

update-locale LANG=de_CH.UTF-8 LC_MESSAGES=en_GB.UTF-8

would do the right thing.

Making it settable by d-i during installation and by "dpkg-reconfigure
locales" is another story and probably requires someone to come up
with wording and flow for the prompts that is not too distracting to
people not using this feature.

Hope that helps,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120409133643.GB2475@burratino

Bug#634261: iceweasel 5.0 does not start on sparc, bus error

[Jonathan Nieder]

tags 634261 + upstream
quit

Hi Mike,

FYI:

Jurij Smakov wrote:

> For the record, I do not consider this bug to be RC. As far as I know, 
> it only manifested itself for iceweasel and only because iceweasel 
> does really funky things with its symbols. The bug now contains enough 
> information for a useful upstream report, however I don't intend to 
> file one.

Thanks, both.

Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120409022448.GA10727@burratino

Bug#666043: libc6-dev: unusable due to missing

[Jonathan Nieder]

tags 666043 + moreinfo
quit

Hi,

Raphael Manfredi wrote:

> The packaged  file does a:
>
>   #include 
>
> but that file is missing from the package, hence the  header
> cannot be included in programs.

 $ dpkg-query -S /usr/include/i386-linux-gnu/sys/ucontext.h 
 libc6-dev: /usr/include/i386-linux-gnu/sys/ucontext.h
 $ dpkg-query -W libc6-dev
 libc6-dev  2.13-27

What actual error message are you getting from your compiler, and with
what command line?

Thanks for writing,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120328142450.GC7038@burratino

Re: lenny->squeeze: Upgrading locales causes broken en_US.utf8 locale during upgrade

[Jonathan Nieder]

tags 585737 =
reassign 660669 locales 2.11.3-3
forcemerge 585737 660669
affects 585737 + upgrade-reports
quit

Hi Josh,

Josh Triplett wrote:

> I just upgraded an old system from lenny to squeeze.  The upgrade run
> included the "locales" package.  Early on in the upgrade, apt unpacked
> the replacement locales, but didn't actually configure it at that time.
> Throughout the rest of the upgrade, I got numerous different and
> repeated messages about broken locales, such as these:
>
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LC_COLLATE = "C",
> LANG = "en_US.utf8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> /usr/bin/mandb: can't set the locale; make sure $LC_* and $LANG are correct
> manconv: can't set the locale; make sure $LC_* and $LANG are correct
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
>
> Please make sure that upgrading the locales package does not break
> configured locales during the upgrade.

This is .  Is it reproducible for you
(for example by downgrading locales, libc, and perl and running another
upgrade)?  Does it happen in squeeze->wheezy upgrades, too?

Thanks for reporting it.

Sincerely,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120302084558.GA14792@burratino

Bug#660779: ldconfig: should ignore files with names ending in "-gdb.py"

[Jonathan Nieder]

reassign 660779 libstdc++6-4.6-dbg 4.6.2-6
forcemerge 652160 660779
affects 652160 + libc-bin
quit

Hi Samuel,

Samuel Bronson wrote:

> ldconfig: /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16-gdb.py is not an ELF 
> file - it has the wrong magic bytes at the start.
>
> The file in question is from libstdc++6-4.6-dbg (>= 4.6.2-6), and (as
> the name suggests) is a Python script for use with GDB in connection
> with libstdc++.so.6.0.16, and is thus not *supposed* to be an ELF file.

This was fixed in libstdc++6-4.6-dbg 4.6.2-13.

Hope that helps,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120221200223.GA31798@burratino

Bug#660526: [PATCH glibc-2.11.y] Re: is incomplete for POSIX 2008

[Jonathan Nieder]

tags 660526 + upstream patch moreinfo
quit

Hi Petr and Jérémy,

Jérémy Compostella wrote:

> I apology if this bug has already been reported but I am unable to find
> it through the web bug report interface.
>
> POSIX 2008 requires that  expose ssize_t, va_list, and getline
> (among others) if _POSIX_C_SOURCE is 200809L or greater.  However, the
> 2.11 glibc does not conform to this (see
> http://sourceware.org/bugzilla/show_bug.cgi?id=11125).
>
> I'm currently working on some GNU coreutils and since I'm working with
> the Debian squeeze I got this issue. See thread
> http://lists.gnu.org/archive/html/coreutils/2012-02/msg00128.html
>
> As I said in the above thread, this issue has been fixed in GNU libc
> cd2f000c074b07931bd78ab5ff5fa3c0f7db628a commit. I wonder if you could
> backport this bug fix ?

There are lots of XPG7 conformance fixes that glibc 2.11.y is missing,
but I see no harm in taking this one since it seems to be affecting
people.  Petr, how about this patch, and what is the appropriate mailing
list for proposing cherry-picks like this?

-- >8 --
From: Ulrich Drepper 
Date: Sun, 10 Jan 2010 00:39:22 -0800
Subject: Fix standalone stdio.h inclusion.

(cherry picked from commit cd2f000c074b07931bd78ab5ff5fa3c0f7db628a)

Skipping conformance testing bits since XPG7 testing did not land
until glibc-2.12~297.
---
 ChangeLog |9 +
 libio/stdio.h |   24 ++--
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2e9a5163..3ab295f0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-01-10  Ulrich Drepper  
+
+   [BZ #11125]
+   * libio/stdio.h: Define va_list, off_t, and ssize_t.
+
+2010-01-09  Ulrich Drepper  
+
+   * libio/stdio.h: Define va_list also for XPG7.
+
 2011-05-29  Ulrich Drepper  
 
[BZ #12350]
diff --git a/libio/stdio.h b/libio/stdio.h
index a6d24e54..bf16b3ff 100644
--- a/libio/stdio.h
+++ b/libio/stdio.h
@@ -1,5 +1,5 @@
 /* Define ISO C stdio on top of C++ iostreams.
-   Copyright (C) 1991, 1994-2007, 2008, 2009 Free Software Foundation, Inc.
+   Copyright (C) 1991, 1994-2008, 2009, 2010 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -74,7 +74,7 @@ typedef struct _IO_FILE __FILE;
 
 #include 
 
-#ifdef __USE_XOPEN
+#if defined __USE_XOPEN || defined __USE_XOPEN2K8
 # ifdef __GNUC__
 #  ifndef _VA_LIST_DEFINED
 typedef _G_va_list va_list;
@@ -85,6 +85,26 @@ typedef _G_va_list va_list;
 # endif
 #endif
 
+#ifdef __USE_XOPEN2K8
+# ifndef __off_t_defined
+# ifndef __USE_FILE_OFFSET64
+typedef __off_t off_t;
+# else
+typedef __off64_t off_t;
+# endif
+# define __off_t_defined
+# endif
+# if defined __USE_LARGEFILE64 && !defined __off64_t_defined
+typedef __off64_t off64_t;
+# define __off64_t_defined
+# endif
+
+# ifndef __ssize_t_defined
+typedef __ssize_t ssize_t;
+# define __ssize_t_defined
+# endif
+#endif
+
 /* The type of the second argument to `fgetpos' and `fsetpos'.  */
 __BEGIN_NAMESPACE_STD
 #ifndef __USE_FILE_OFFSET64
-- 
1.7.9




--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120220003317.GB969@burratino

Bug#658278: ld.so segfaults on wrong input

[Jonathan Nieder]

severity 658278 wishlist
tags 658278 + moreinfo
quit

Goswin von Brederlow wrote:

> It has a different interpreter in its elf section. Ld.so could check
> that to determine wether the elf file is one it should care about.

A common use case is testing updated versions of ld.so by running
binaries explicitly using the ld.so binary.  I don't see how your
proposed enhancement is consistent with that.

> A segfault is never correct behaviour and needs to be fixed in ld.so.

If my program is built against one DSO and the caller uses LD_PRELOAD
or LD_LIBRARY_PATH to replace it with something completely different,
I'd expect segfaults from time to time (due to incompatible struct
layouts, for example).

However, maybe it is avoidable.  Often that kind of misconfiguration
gets caught by other checks, like the following:

foo: symbol lookup error: foo: undefined symbol: some_symbol

Before veering too far in that direction, what is your use case?  Was
something broken by this?  Maybe there is a simpler way to accomplish
it.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120208102656.GA3356@burratino

Bug#659064: libc6 - Includes file in /lib64

[Jonathan Nieder]

Bastian Blank wrote:
> On Wed, Feb 08, 2012 at 12:09:31AM +0100, Aurelien Jarno wrote:
>> On Wed, Feb 08, 2012 at 12:05:20AM +0100, Bastian Blank wrote:

>>> It exists in the filesystem as relict from the old package.
>>
>> We have a preinst script making sure it is replaced from a symlink to a
>> directory.
>
> There is not preinst script running in the early stages of the
> bootstrap.

There is also not typically an old package that has left behind a
symlink in the early stages of bootstrap.  Are you bootstrapping
wheezy on top of an existing installation of squeeze or something?

Curious,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012020809.GA6281@burratino

Bug#659064: libc6 - Includes file in /lib64

[Jonathan Nieder]

Hi Bastian,

Bastian Blank wrote:

> libc6 includes the file /lib64/ld-linux-x86-64.so.2. It was decided that
> this should not happen, because neither dpkg nor any of the bootstrap
> tools handles this properly. See #514015 for further informations.

libc6 does not contain a /lib64 -> /lib symlink any more.  Could
you describe the symptoms?

Thanks,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012020741.GA2872@burratino

Re: Missing accept4 for ia64

[Jonathan Nieder]

Jonathan Nieder wrote:

> You may want to file a bug report with a patch for udev to Depend on
> libc6.1 (>= 2.13-25) [ia64].  See the libc changelog for details.

On second thought, since there was a symbols bump, a binnmu of udev
against libc6-dev 2.13-25 or later should be enough.


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120204192830.GD22928@burratino

Re: Missing accept4 for ia64

[Jonathan Nieder]

Émeric Maschino wrote:

> So, what is thus the "fixed" package version I should wait for?

You may want to file a bug report with a patch for udev to Depend on
libc6.1 (>= 2.13-25) [ia64].  See the libc changelog for details.

Hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120204185204.GA22928@burratino

Re: Missing accept4 for ia64

[Jonathan Nieder]

Aurelien Jarno wrote:
> On Sat, Jan 28, 2012 at 04:04:07PM -0600, Jonathan Nieder wrote:
>> Aurelien Jarno wrote:

>>> Yes, it should probably work. Should I bump the build-dep on
>>> linux-libc-dev to a recent version (in that case which version?).
>>
>> (>= 3.2.1-1) [ia64]
>
> This gives the version, not if the version should be bumped or not.

Yes, the build-dep should be bumped.  udev is broken without a working
accept4 (bug#648325).


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120128221420.GA9636@burratino

Re: Missing accept4 for ia64

[Jonathan Nieder]

Aurelien Jarno wrote:
> On Sat, Jan 28, 2012 at 09:52:36PM +, Ben Hutchings wrote:

>> accept4() was not implemented by Linux on ia64 for a long time.  I
>> believe eglibc will define the C wrapper automatically when built
>> against the updated linux-libc-dev.
>
> Yes, it should probably work. Should I bump the build-dep on
> linux-libc-dev to a recent version (in that case which version?).

(>= 3.2.1-1) [ia64]

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120128220407.GC8958@burratino

Bug#655711: ldconfig makes system loader /lib/ld-linux.so.2 to be linked to 3rd party loader in /lib directory

[Jonathan Nieder]

Hi,

venkatesh_pra...@mcafee.com wrote:

> Version: 2.13-0ubuntu13

Can you reproduce this with libc-bin from Debian squeeze or sid?  If
not, this is not the place to report it.  Ubuntu bugs are tracked on
launchpad.

> System having installed with some 3rd party loaders (ld-.so.x)
> in /lib directory. With these loaders present if we run ldconfig,
> its removing the system loader symbolic link ld-linux.so.2 in /lib
> directory from /lib/i286-linux-gnu/ld-2.13.so and creating the
> symbolic link to one of the 3rd party loaders(in my case link to
> ld-nails.so.2) present in /lib directory.

Is this a regression?  Did previous versions ignore ld-nails.so.2 for
some reason?

It looks like what is happening is that ld-nails.so.2 encodes a SONAME
of ld-linux.so.2 (you can check with "readelf -d /lib/ld-nails.so.2 |
grep SONAME"), so ldconfig makes a symlink to it.  The dynamic loader
is considered a shared library just like /lib/lib* and has been so at
least since ldconfig was added to glibc in 1999.

If one wants a private library, so as not to have ldconfig
automatically creating symlinks to it, it cannot go straight in /lib
or anywhere else on the library path but should be placed elsewhere
(for example somewhere in /opt).  Alternatively, if this is a public
library but is not meant to provide the ld-linux.so.2 interface, it
should encode a different soname.

Hope that helps,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113200220.GB1825@burratino

Bug#654835: libc/NEWS.Debian: please suggest use of LIBRARY_PATH and CPATH envvars

[Jonathan Nieder]

Package: libc6
Version: 2.13-24
Severity: minor
Justification: documentation
Tags: patch

libc6's NEWS.Debian explains:

   you might try to pass the following option to your
compiler:

  -B/usr/lib/ -I/usr/include/

Lately I've been building gcc trunk from time to time, and as noted in
bug#644990 there's no obvious place to put those options to ensure
they get passed to the stage1 compiler.  Then suddenly it occured to
me that the usual LIBRARY_PATH and CPATH environment variables would
be a less fussy way to tell the compiler what paths to use.

It works. :)

How about this patch?  Hopefully it can save future readers and bug
triagers some time.
---
 debian/changelog  |8 
 debian/debhelper.in/libc.NEWS |6 ++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 7847ec9d..0dfeb6b2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+eglibc (2.13-25) UNRELEASED; urgency=low
+
+  * debhelper.in/libc.NEWS: suggest environment variables as an
+alternative for build systems that make it hard to pass custom
+arguments like -B and -I to the compiler.
+
+ -- Jonathan Nieder   Thu, 05 Jan 2012 19:20:52 -0600
+
 eglibc (2.13-24) unstable; urgency=low
 
   * patches/m68k/cvs-byteswap.diff: fix m68k optimized version of 
diff --git a/debian/debhelper.in/libc.NEWS b/debian/debhelper.in/libc.NEWS
index e069cdc2..cb5f9e7f 100644
--- a/debian/debhelper.in/libc.NEWS
+++ b/debian/debhelper.in/libc.NEWS
@@ -15,6 +15,12 @@ eglibc (2.13-17) unstable; urgency=low
 
 -B/usr/lib/ -I/usr/include/
 
+  Or set the LIBRARY_PATH and CPATH environment variables:
+
+LIBRARY_PATH=/usr/lib/
+CPATH=/usr/include/
+export LIBRARY_PATH CPATH
+
  -- Aurelien Jarno   Tue, 09 Aug 2011 19:58:28 +0200 
 
 eglibc (2.13-7) unstable; urgency=low
-- 
1.7.8.2




-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120106012714.ga18...@elie.hsd1.il.comcast.net

Bug#653178: "/bin/cat whatever just segfaults" (Re: Bug#653178: reopen)

[Jonathan Nieder]

Hi Eric,

Eric Valette wrote:

> reopen #653179

Rather than fiddling with metadata, why not provide some information
to help others reproduce or otherwise understand your report?  /bin/cat
works fine for me.  [1] has some hints.

Sorry for the trouble,
Jonathan

[1] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120103032538.ga2...@elie.hsd1.il.comcast.net

Bug#636286: tagging 636286

[Jonathan Nieder]

Thorsten Glaser wrote:
> Aurelien Jarno dixit:

>> tags 636286 + wontfix
>
> Uhm, why? If someone working for glibc upstream says that the
> locale files produced by the Debian patched version of glibc
> are invalid…

The wontfix tag has a somewhat complicated role.  In practice, it
generally means that the people responsible for that package are not
going to be working on fixing this particular bug, and although that's
a kind of strange piece of metadata to maintain, I tend to find it
much more helpful than no response at all.

While it would have been even nicer if the maintainer had said why
and what avenues, if any, exist for helping out, I don't think that's
necessary.  Even for bugs marked wontfix, help investigating and
working towards a fix tends to be appreciated.

Sorry for the trouble and hope that helps,
Jonathan



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120101234846.gc25...@elie.hsd1.il.comcast.net

Bug#653446: ldconfig: /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py is not an ELF file

[Jonathan Nieder]

reassign 653446 libstdc++6-4.6-dbg 4.6.2-9
severity 652160 minor
merge 652160 653446
quit

Julian Andres Klode wrote:

> Since some weeks, whenever ldconfig is run during an upgrade, I get
> the following warning:
>
> ldconfig: /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py is not an ELF 
> file - it has the wrong magic bytes at the start.
>
> This means that either the .py file is in the wrong location, or
> that ldconfig should not warn about those files.

Yep.

Thanks,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111229010413.GA18425@elie.Belkin

Bug#652356: please use argument-safe bswap macros on all architectures

[Jonathan Nieder]

Aurelien Jarno wrote:

> If you are not an m68k porter, you should simply stop to care about
> m68k porting issues. 

There are kinder ways to say that.

Thorsten, can you test this patch or arrange for it to be tested?

commit fb3ed187
Author: Andreas Schwab 
Date:   Sun Mar 6 19:52:43 2011 +0100

m68k: reimplement byteswap macros as inlines

diff --git a/ChangeLog.m68k b/ChangeLog.m68k
index 6edab560..5e45243a 100644
--- a/ChangeLog.m68k
+++ b/ChangeLog.m68k
@@ -1,3 +1,8 @@
+2011-03-06  Andreas Schwab  
+
+   * sysdeps/m68k/bits/byteswap.h (__bswap_16, __bswap_32)
+   (__bswap_64): Implement as inline functions.
+
 2011-01-18  Andreas Schwab  
 
* sysdeps/unix/sysv/linux/m68k/bits/mman.h (MADV_HUGEPAGE)
diff --git a/sysdeps/m68k/bits/byteswap.h b/sysdeps/m68k/bits/byteswap.h
index a2546c9a..4f31d95b 100644
--- a/sysdeps/m68k/bits/byteswap.h
+++ b/sysdeps/m68k/bits/byteswap.h
@@ -1,5 +1,5 @@
 /* Macros to swap the order of bytes in integer values.  m68k version.
-   Copyright (C) 1997, 2002, 2008 Free Software Foundation, Inc.
+   Copyright (C) 1997, 2002, 2008, 2011 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -30,36 +30,29 @@
 #define __bswap_constant_16(x) \
  x) >> 8) & 0xffu) | (((x) & 0xffu) << 8))
 
-#ifdef __GNUC__
-# define __bswap_16(x) \
-(__extension__   \
- ({ unsigned short int __bsx = (x); __bswap_constant_16 (__bsx); }))
-#else
 static __inline unsigned short int
 __bswap_16 (unsigned short int __bsx)
 {
   return __bswap_constant_16 (__bsx);
 }
-#endif
 
 /* Swap bytes in 32 bit value.  */
 #define __bswap_constant_32(x) \
  x) & 0xff00u) >> 24) | (((x) & 0x00ffu) >>  8) |\
   (((x) & 0xff00u) <<  8) | (((x) & 0x00ffu) << 24))
 
-#if defined __GNUC__ && __GNUC__ >= 2 && !defined(__mcoldfire__)
-# define __bswap_32(x) \
-  __extension__\
-  ({ unsigned int __bswap_32_v;\
- if (__builtin_constant_p (x)) \
-   __bswap_32_v = __bswap_constant_32 (x); \
- else  \
-   __asm__ __volatile__ ("ror%.w %#8, %0;" \
-"swap %0;" \
-"ror%.w %#8, %0"   \
-: "=d" (__bswap_32_v)  \
-: "0" ((unsigned int) (x)));   \
- __bswap_32_v; })
+#if !defined(__mcoldfire__)
+static __inline unsigned int
+__bswap_32 (unsigned int __bsx)
+{
+  if (__builtin_constant_p (__bsx))
+return __bswap_constant_32 (__bsx);
+  __asm__ __volatile__ ("ror%.w %#8, %0;"
+   "swap %0;"
+   "ror%.w %#8, %0"
+   : "+d" (__bsx));
+  return __bsx;
+}
 #else
 static __inline unsigned int
 __bswap_32 (unsigned int __bsx)
@@ -81,19 +74,14 @@ __bswap_32 (unsigned int __bsx)
   | (((x) & 0x00ffull) << 56))
 
 /* Swap bytes in 64 bit value.  */
-# define __bswap_64(x) \
-  __extension__
\
-  ({ union { unsigned long long int __ll;  \
-unsigned long int __l[2]; } __bswap_64_v, __bswap_64_r;\
- if (__builtin_constant_p (x)) \
-   __bswap_64_r.__ll = __bswap_constant_64 (x);\
- else  \
-   {   \
-__bswap_64_v.__ll = (x);   \
-__bswap_64_r.__l[0] = __bswap_32 (__bswap_64_v.__l[1]);\
-__bswap_64_r.__l[1] = __bswap_32 (__bswap_64_v.__l[0]);\
-   }   \
- __bswap_64_r.__ll; })
+static __inline unsigned long long
+__bswap_64 (unsigned long long __bsx)
+{
+  if (__builtin_constant_p (__bsx))
+return __bswap_constant_64 (__bsx);
+  return (__bswap_32 (__bsx >> 32)
+ | ((unsigned long long) __bswap_32 (__bsx) << 32));
+}
 #endif
 
 #endif /* _BITS_BYTESWAP_H */



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111217215254.gb22...@elie.hsd1.il.comcast.net

Bug#649164: getconf: missing POSIX_V7_THREADS_CFLAGS, POSIX_V7_THREADS_LDFLAGS variables

[Jonathan Nieder]

Package: libc-bin
Version: 2.13-21
Severity: wishlist
Justification: POSIX.1-2008 XCU.c99 extended description, table 4-6
Tags: upstream

Hi,

POSIX says:

In addition to the type size programming environments above,
all implementations support a multi-threaded programming
environment that is orthogonal to all the programming
environments listed above. The getconf utility can be used to
get flags for the threaded environment, as indicated in
Table 4-6.

and continues by documenting that

getconf POSIX_V7_THREADS_CFLAGS
getconf POSIX_V7_THREADS_LDFLAGS

retrieve the compiler flags and linker flags, respectively, for
building multithreaded programs.  glibc getconf does not seem to
support this.

Certainly not urgent, but thought I should report it before I forget.

Sincerely,
Jonathan

(Side note: on amd64, "getconf -v POSIX_V7_LP64_OFF64 POSIX2_VERSION"
works but "getconf -v POSIX_V7_ILP32_OFF32 POSIX2_VERSION" produces
"getconf: Couldn't execute /usr/lib/getconf/POSIX_V7_ILP32_OFF32: No
such file or directory".  So something seems awry, though I care even
less about it.  Please let me know if you would like a report about
that.)



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2018120103.ga24...@elie.hsd1.il.comcast.net

Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

[Jonathan Nieder]

# affects most development libraries, not just libc
reassign 648889 general
forcemerge 637232 648889
quit

Hi Wolfgang,

Wolfgang Tichy wrote:

> I just tried to comiple some code with the intel compiler and got:
> /usr/include/features.h(323): catastrophic error: could not open source file
> "bits/predefs.h"
>   #include 
>
> The reason seems to be that /usr/include/features.h includes bits/predefs.h
> which does not exist in  /usr/include/ . However, it exists in
> /usr/include/x86_64-linux-gnu/ .

See [1] for some background.

/usr/share/doc/libc6/NEWS.Debian.gz explains:

  Starting with the eglibc package version 2.13-5, the libraries are
  shipped in the multiarch directory /lib/ instead of the more
  traditional /lib, where  is the multiarch triplet and can be
  retrieved with 'dpkg-architecture -qDEB_HOST_MULTIARCH'. Similarly the
  includes are now shipped in /usr/include/ instead of the more
  traditional /usr/include.

  The toolchain in Debian has been updated to cope with that, and most
  build systems should be unaffected. If you are using a non-Debian
  toolchain to build your software and it is not able to cope with
  multiarch, you might try to pass the following option to your
  compiler:

-B/usr/lib/ -I/usr/include/

I believe the best long-term solution would be to teach the Intel
compiler to use the /usr/{lib,include}/ directories so it can
find libraries and header files for the target architecture as they
move to the new location.

In the short term, however, you will probably need to configure your
compiler differently (perhaps by adding appropriate flags to your
definition of the CC variable).  Does the Intel compiler support the
-B and -I options?

Thanks for writing,
Jonathan

[1] http://wiki.debian.org/Multiarch



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2015215943.ga25...@elie.hsd1.il.comcast.net

Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility

[Jonathan Nieder]

Jonathan Nieder wrote:
> Lionel Elie Mamane wrote:

>> And I've just checked for overlap by running
>> these on the latrace output:
[...]
> Could you try the analagous checks with strcpy and stpcpy?

Ah, I have another idea.  Could you try the libc6 package from wheezy
or sid?

If my hunch is right, it will work fine, and you ran into something
like PR12159 (bug#635885).



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111017134425.ga4...@elie.hsd1.il.comcast.net

Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility

[Jonathan Nieder]

Hi Lionel,

Lionel Elie Mamane wrote:

> And I've just checked for overlap by running
> these on the latrace output:
>
> grep ' memcpy(' | sed 's/[(,)]/ /g' | gawk '{if ( strtonum($8) <= 
> strtonum($5) && strtonum($8) + strtonum($11) >= strtonum($5)) print "overlap: 
> " $5 " " $8 " " $11 }'
> grep ' memcpy(' | sed 's/[(,)]/ /g' | gawk '{if ( strtonum($8) >= 
> strtonum($5) && strtonum($5) + strtonum($11) >= strtonum($8)) print "overlap: 
> " $5 " " $8 " " $11 }'

Could you try the analagous checks with strcpy and stpcpy?



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111017101423.gc22...@elie.hsd1.il.comcast.net

Bug#644990: NEWS.Debian.gz: s/$arch/

[Jonathan Nieder]

Sedat Dilek wrote:
> On Fri, Oct 14, 2011 at 9:44 PM, Jonathan Nieder  wrote:

>> It means that you might want to pass those flags to the compiler.
>> The compiler doesn't examine any environment variables, so your
>> "export CFLAGS" incantation isn't going to do that, depending on the
>> build system.
>
> You mean something like "make CC='gcc ...'" ?
> What exactly do I need to pass?

I mean

gcc -B... -I... -o hello-world hello-world.c

Beyond that, it's going to depend on the build system of the project
you're working on, no?  That's why a wrapper like

#!/bin/sh
exec /path/to/gcc -B... -I... "$@"

can save trouble.

>> When building a compiler, there is a bootstrap step, meaning there are
>> multiple compilers to pass the flags to.  I thought there was already
>> a bug report about making this easier (#637232) which unfortunately no
>> one seems to be working on.
>
> Unfortunately.

Actually, you seem to have been working on it. :)  Thanks for your
experiments.

[...]
> With my 2 workarounds I can use my gcc-4.7 binaries OOTB. No
> wrapper-script etc. (so I prefer my way).

You mean with the symlinks?  But won't you need symlinks for every library
in /lib/ and /usr/lib/, including:

 - libz
 - libbz2
 - libncurses
 - libpng
 - gcj libs
 - libflac
 - libgl
 - libice
 - libsm
 - libx11
 - libxau
 - ...
 - libarchive
 - libasound
 - libavcodec
 - libc
 etc

?  I fear I'm missing something.

>> But what does this have to do with the "" text in libc6-dev's
>> NEWS.Debian.gz?
>
> I wanted to point out that building with -B and -I options might not
> be enough to really use your generated new binaries.

Ok, so it sounds like the text really was unclear.  The _intent_ was
that to use a compiler named "foo", you might want to try

foo -B... -I... ...

or some equivalent command.  For example, during the gcc build, you
might want to configure the build system to use

xgcc -B... -I... ...

After a new gcc is built, you might want to configure other projects
to invoke

gcc -B... -I... ...

The text is not meant to be a recipe that works in all cases (since
libc6 is just a C library, not a reference manual for all compilers
and build systems ever written), but just a heads up about a change
that can affect people.

Thanks for noticing.  Any ideas about how to make it clearer?



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111014201034.gc16...@elie.hsd1.il.comcast.net

Bug#644990: NEWS.Debian.gz: s/$arch/

[Jonathan Nieder]

Jonathan Nieder wrote:

> The compiler doesn't examine any environment variables

(Just to be clear, this is a lie.  The compiler does examine some
environment variables, though CFLAGS is not one of them.)

[...]
> But what does this have to do with the "" text in libc6-dev's
> NEWS.Debian.gz?

This question is still relevant.  We already knew the changes in file
locations affect people.  So I guess you were saying the NEWS.Debian.gz
should also provide advice about various compiler build systems and
build systems of projects that use compilers.

Consider the downside: when upgrading, _every_ sysadmin with libc6-dev
and apt-listchanges installed would be confronted by that wall of text.

So there is likely to be a better way to organize this information.
Suggested text for an additional file, for example, would be welcome,
especially in the form of a patch or a simple, attached, ready-to-go
README.

"Why do you keep asking for patches?" you might wonder.  It is because
patches make it possible to suggest an improvement without
significantly adding to the maintainer's (Aurelien's) workload.
Copying, pasting, and tweaking might seem easy, but even it takes
time.

Anyway, this particular report is about the NEWS.Debian.gz text.  It
seems you found its description of  to be unclear.  Please
stick to that in this report, and address other bugs elsewhere so a
person can follow up on your work without reading through too much
irrelevant stuff.

Hope that helps,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2011101429.gb16...@elie.hsd1.il.comcast.net

Bug#644990: NEWS.Debian.gz: s/$arch/

[Jonathan Nieder]

Sedat Dilek wrote:

> I am unsure how to interpret "you might try to pass the following
> option to your:  -B/usr/lib/ -I/usr/include/"?
>
> Normally, I would expect to do:
>
> export CFLAGS="$CFLAGS -B/usr/lib/ -I/usr/include/"
>
> But in case of gcc-trunk upstream this change impacts:
[...]

It means that you might want to pass those flags to the compiler.
The compiler doesn't examine any environment variables, so your
"export CFLAGS" incantation isn't going to do that, depending on the
build system.

When building a compiler, there is a bootstrap step, meaning there are
multiple compilers to pass the flags to.  I thought there was already
a bug report about making this easier (#637232) which unfortunately no
one seems to be working on.

> The generated compiler needs a wrapper-script to use -B and -I options.
> BTW, I could compile mesa, but not use the same wrapper-script with
> kernel-buildsystem from Debian Kernel Team.

That's probably because in debian/config.defines, we have

compiler: 'gcc-4.5'

So if your gcc-4.5 comes from upstream, you would need to install a
/usr/local/bin/gcc-4.5 wrapper, too.

But what does this have to do with the "" text in libc6-dev's
NEWS.Debian.gz?



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111014194410.ga16...@elie.hsd1.il.comcast.net

Bug#644990: NEWS.Debian.gz: s/$arch/

[Jonathan Nieder]

Hi Sedat,

Sedat Dilek wrote:

> /usr/share/doc/libc6/NEWS.Debian.gz says:
[...]
>  you might try to pass the following option to your
>   compiler:
>
> -B/usr/lib/$arch -I/usr/include/$arch
>
> Better use commonly used  when talking about multiarch [1] instead:
>
> -B/usr/lib/ -I/usr/include/

They seem equally unclear to me.  It might make sense to say something
like "where $arch is the name printed by 'dpkg-architecture
-qDEB_HOST_MULTIARCH' --- for example, i386-linux-gnu" or "where
 is [...]".

Care to write a patch?

Thanks,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111011200746.ge...@elie.hsd1.il.comcast.net

Bug#644986: i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?

[Jonathan Nieder]

reassign 644986 general
severity 644986 critical
merge 637232 644986
quit

Sedat Dilek wrote:

> I played again with CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET by exporting 
> them.
[...]
> -B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE} ...
> ...does NOT catch the problem with crt*.o files.

Last time we went through this, didn't we discover that one has to set

 FLAGS_FOR_TARGET (instead of CFLAGS_FOR_TARGET or CXXFLAGS_FOR_TARGET)

and

 on the "make" command line (instead of through the environment or as
 a ./configure argument)

?  Yes, I know it is clunky.

Reassigning to "general" because the underlying problem (Debian as a
whole is moving to multiarch paths, and we don't provide enough help
with building upstream toolchains that don't know about that) is not
at all specific to libc6-dev.  Progress in the form of code or
documentation, in Debian or upstream, would be welcome as always.

Cheers,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111011195357.gb...@elie.hsd1.il.comcast.net

Bug#644986: i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?

[Jonathan Nieder]

Hi Sedat,

Sedat Dilek wrote:

> these problems here were already discussed on #multiarch and reported
> by me (see for example #636116 or #637218), but still exist.

Those look like different bugs.  #636116 was about libc6-dev-amd64
failing to unpack!  #629819 was about crti.o et al moving to the
multiarch location without any warning about the need for build
scripts to be adjusted and was fixed by adding a NEWS.Debian.gz
describing that need and giving some advice.  #637218 was the
corresponding problem for headers.  Similarly, #634821 was about
libgcc_s.so.1 et al moving and breaking old gcc installations without
warning and was fixed by adding a Breaks.

This time, you are reporting that you needed workarounds to build
upstream gcc without patching it or adding special ./configure
options:

[...]
> # ls -l /usr/include/gnu/stubs-32.h
> lrwxrwxrwx 1 root root 32 Sep  5 17:19 /usr/include/gnu/stubs-32.h -> 
> ../i386-linux-gnu/gnu/stubs-32.h
[...]
> # ls -l /usr/lib/crt*.o
> lrwxrwxrwx 1 root root 21 Sep  5 18:24 /usr/lib/crt1.o -> 
> i386-linux-gnu/crt1.o
> lrwxrwxrwx 1 root root 21 Sep  5 18:24 /usr/lib/crti.o -> 
> i386-linux-gnu/crti.o
> lrwxrwxrwx 1 root root 21 Sep  5 18:24 /usr/lib/crtn.o -> 
> i386-linux-gnu/crtn.o

This is #637232, which is about finding some way to get these things
working without making each user spend too much time.

More and more headers and libraries (not just those provided by
libc6-dev!) are moving to the multiarch locations, so adding symlinks
one by one does not seem like a viable strategy for that.  See
http://bugs.debian.org/637232 for more details.

[...]
> Again I tried to compile a gcc-4.7 snapshot tarball [1] with my
> (updated) build-script.

Something that might be useful is to add a
"building-premultiarch-toolchain.txt" to libc6-dev or some similar
package, explaining how to tell the gcc build system where the
bootstrap compiler should look for multiarch libs and headers.

Because gcc's configure script is a little insane, this
is more complicated than the incantation described in NEWS.Debian.gz,
though only cosmetically so.  Something like:

  make FLAGS_FOR_TARGET='-B$(build_tooldir)/bin/ '\
'-B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include '\
'-isystem $(build_tooldir)/sys-include '\
"-B/usr/lib/$DEB_HOST_MULTIARCH" \
"-I/usr/include/$DEB_HOST_MULTIARCH" \
install

Yes, this has to be set through a makefile variable, not the configure
script, since no one bothered to wire the latter up for it.

Yes, presumably the settings that come before '-B/usr/lib/i386-linux-gnu'
are needed.  They are the default from the toplevel Makefile, and the
Makefile does not provide a way to add extra FLAGS_FOR_TARGET
without overriding the existing ones.

When I tried this[*], I also had set CFLAGS_FOR_TARGET and
CXXFLAGS_FOR_TARGET as configure arguments and BOOT_CFLAGS on the
"make" command line, but I believe you tested with just
FLAGS_FOR_TARGET and found it to work ok.

> A succesfully compiled gcc upstream snapshot tarballs is a testcase
> for me before I start any compilation of a MIPSEL toolchain for a
> router project called freetz.

Good luck!  You might also want to look into the gcc-snapshot package,
which is already patched to handle the multiarch paths both at build
time and at runtime.

Will respond to your other message separately.

Hope that helps,
Jonathan

[*] http://bugs.debian.org/637218



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111011194821.ga...@elie.hsd1.il.comcast.net

Bug#644270: strcoll(): collation sequences of locales unspecified

[Jonathan Nieder]

reassign 644270 manpages-dev 3.32-0.2
retitle 644270 strcoll(3): please make locale(5) easier to find
severity 644270 wishlist

Hi,

Filipus Klutiero wrote:

> strcoll(3) explains that:
>
>> The strcoll() function compares the two strings s1 and s2. It returns an
>> integer less than, equal to, or greater than zero if s1 is found,
>> respectively, to be less than, to match, or be greater than s2. The
>> comparison is based on strings interpreted as appropriate for the
>> program's current locale for category LC_COLLATE. (See setlocale(3).)
>
> Unfortunately, it seems the way collation happens depending on the
> LC_COLLATE locale is unspecified. I couldn't find any description, even
> upstream.

The strcoll(3) manpage is from manpages-dev, not eglibc.  Anyway, the
behavior is as described in POSIX[1].  Clarifying text welcome.

Hope that helps,
Jonathan

[1] http://www.unix.org/2008edition/



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111004193750.GA28592@elie

Bug#644023: FTBFS on kfreebsd-i386

[Jonathan Nieder]

Petr Salinger wrote:

> It effectively test return code of
>
>fprintf (fp, "%2147483648d%2147483648d", 1, 1);
>
> The printf family returns int and should return number of written bytes.
> It therefore cannot exceed MAX_INT.
>
> But the test tries to print twice entry with width MAX_INT+1.
> I would understand the test with i.e. 2147483640
> or six time 512 MB.

Yeah, your suggested test would be a more precise test for the
original bug[1].

C99 (N1256 §7.19.6.1.4) only tells us that the field width is a
"nonnegative decimal integer".  It would be nice to clarify with the C
working group whether a field width that doesn't fit into an "int"
triggers undefined behavior or if the implementation is obligated to
catch it.

> On kfreebsd-amd64, it tries to
> mmap(0,0x80001000,PROT_READ|PROT_WRITE,MAP_ANON|MAP_TYPE|MAP_PRIVATE,0x,0)
> and fails.

Sounds buggy.  In fact, there are at least a couple of seemingly buggy
aspects here.

 - read_int does not check for overflow
 - read_int returns "unsigned int", but "prec" and "width" are ints
 - the "for (; (size_t) nspecs_done < nspecs; ++nspecs_done)" loop
   does not check for overflow when deciding the initial work buffer
   size
 - the private __parse_one_spec API (and public parse_printf_format
   API) does not seem to include a way to indicate overflow

Anyway, how about this patch?  It implements your 6 times 512 MiB idea
(well, 3 times 1 GiB because I'm lazy) and adds a new test for the
related bug Robert found (which gets masked on Linux by malloc() not
bothering to try to fulfill such huge requests --- maybe it would be
possible to tweak it so it can fail on Linux, too).
---
[1] http://sourceware.org/bugzilla/show_bug.cgi?id=5424

 stdio-common/Makefile |2 +-
 stdio-common/bug22.c  |5 +++--
 stdio-common/bug22a.c |   33 +
 3 files changed, 37 insertions(+), 3 deletions(-)
 create mode 100644 stdio-common/bug22a.c

diff --git a/stdio-common/Makefile b/stdio-common/Makefile
index 006f5468..3be668cc 100644
--- a/stdio-common/Makefile
+++ b/stdio-common/Makefile
@@ -60,7 +60,7 @@ tests := tstscanf test_rdwr test-popen tstgetln test-fseek \
 tst-popen tst-unlockedio tst-fmemopen2 tst-put-error tst-fgets \
 tst-fwrite bug16 bug17 tst-swscanf tst-sprintf2 bug18 bug18a \
 bug19 bug19a tst-popen2 scanf13 scanf14 scanf15 bug20 bug21 bug22 \
-scanf16 scanf17 tst-setvbuf1 tst-grouping bug23 bug24
+bug22a scanf16 scanf17 tst-setvbuf1 tst-grouping bug23 bug24
 
 test-srcs = tst-unbputc tst-printf
 
diff --git a/stdio-common/bug22.c b/stdio-common/bug22.c
index 2228388b..1f59c735 100644
--- a/stdio-common/bug22.c
+++ b/stdio-common/bug22.c
@@ -1,7 +1,8 @@
 /* BZ #5424 */
 #include 
 
-#define N 2147483648
+/* 1 GiB * 3 > INT_MAX bytes */
+#define N 1073741824
 
 #define STRINGIFY(S) #S
 #define MAKE_STR(S) STRINGIFY(S)
@@ -20,7 +21,7 @@ do_test (void)
   return 1;
 }
 
-  ret = fprintf (fp, "%" SN "d%" SN "d", 1, 1);
+  ret = fprintf (fp, "%" SN "d%" SN "d%" SN "d", 1, 1);
 
   printf ("ret = %d\n", ret);
 
diff --git a/stdio-common/bug22a.c b/stdio-common/bug22a.c
new file mode 100644
index ..37efea39
--- /dev/null
+++ b/stdio-common/bug22a.c
@@ -0,0 +1,33 @@
+/* Not in BZ yet */
+#include 
+
+/* 2 GiB == INT_MAX + 1 */
+#define N 2147483648
+
+#define STRINGIFY(S) #S
+#define MAKE_STR(S) STRINGIFY(S)
+
+#define SN MAKE_STR(N)
+
+static int
+do_test (void)
+{
+  int ret;
+
+  FILE *fp = fopen ("/dev/null", "w");
+  if (fp == NULL)
+{
+  puts ("cannot open /dev/null");
+  return 1;
+}
+
+  ret = fprintf (fp, "%" SN "d", 1, 1);
+
+  printf ("ret = %d\n", ret);
+
+  return ret != -1;
+}
+
+#define TIMEOUT 30
+#define TEST_FUNCTION do_test ()
+#include "../test-skeleton.c"
-- 
1.7.7.rc1




--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111003085950.GE17289@elie

Bug#644023: FTBFS on kfreebsd-i386 (testsuite failure)

[Jonathan Nieder]

Robert Millan wrote:

> Encountered regressions that don't match expected failures:
> bug22.out, Error 1

And what is the content of bug22.out?



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111001213732.GA18677@elie

Bug#641868: alpha: fallocate() in libc6.1 but no declaration in fcntl.h

[Jonathan Nieder]

Hi,

Michael Cree wrote:

> The fallocate() interface is present in libc6.1 on Alpha as is easily
> verified by:
[...]
> Only the posix_fallocate() interface is declared in the headers as
> verified by:
[...]
> Source package libtorrent FTBFS because of this.

Yep, looks like glibc-ports's
sysdeps/unix/sysv/linux/alpha/bits/fcntl.h did not get updated at the
same time as cvs/glibc-2_10~159 (Declare fallocate{,64}, 2009-03-03)
and the corresponding changes for other ports.

The source is at  (and the
analagous source from glibc proper is at
).  Care to suggest a patch?  (If
not, this will still be fixed of course; it just takes longer.)  

http://sourceware.org/glibc/wiki/Contribution%20checklist has
contribution guidelines in case someone wants to send a patch directly
to libc-po...@sourceware.org

Thanks,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110917000832.GA8126@elie

Bug#636686: partial upgrade from squeeze to wheezy fails

[Jonathan Nieder]

Adam Heath wrote:

> Well, fixing this in apt won't be good enough, as that version won't
> be made available in stable.

Of course.  But it's still an apt bug, seriously.

As for the case at hand: the more I think about it, the less the
Breaks by libc6 makes sense.  In the motivating example Bug#629670,
as far as I can tell it is libc6-dev that broke perl:

Note (probably harmless): No library found for -lpthread

Of course that problem isn't libc6-dev-specific --- any development
library installed to /usr/lib/$arch instead of /usr/lib could trigger
the same problem.  It is possible (except on armhf and i386) to use
libc/squeeze with gcc/wheezy as a multiarch development environment
and completely avoid that Breaks.

So maybe the Breaks should be from gcc, if from anywhere.  Niko,
what do you think?

Jonathan



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110826210555.ga26...@elie.gateway.2wire.net

Bug#639290: partial upgrade from squeeze to wheezy fails

[Jonathan Nieder]

reassign 639290 apt
quit

Hi again,

Adam Heath wrote:

> 639290 says that you can deconfigure perl.  That is not possible.

Why?  I thought the whole point of having a separate perl and
perl-base is that perl is not essential.

So as an intermediate state during an upgrade, it should be perfectly
fine to deconfigure perl or to upgrade it without immediately
configuring it.

Reassigning to APT.  Please feel free to reassign back to libc6 or
perl when the problem is clearer.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110826054320.ga11...@elie.gateway.2wire.net

Bug#639290: partial upgrade from squeeze to wheezy fails

[Jonathan Nieder]

Hi APT team,

Quick puzzle for you.

Adam Heath wrote:

> E: Could not perform immediate configuration on 'perl'. Please see man
> 5 apt.conf under APT::Immediate-Configure for details. (2)
> ==
>
> libc6(wheezy) breaks perl << 5.12.  perl 5.12 depends on libgdm3.
> libgdm3 pre-depends multiarch-support.  multiarch-support depends on
> libc6(wheezy).
>
> This loop can't be broken by apt, so it complains.
>
> An upgrade or dist-upgrade from squeeze to wheezy *does* work.

The dependencies seem right.  I would expect my package manager to
either unpack the new perl or temporarily deconfigure perl in order to
upgrade libc.  perl should not satisfy dependencies until the new
version is configured because the output of "perl -V:libpth" is wrong,
as described at .

But as pointed out at [*], when APT::Immediate-Configure is set,
"apt-get install" just bails out in this situation instead.  Is that a
libc bug, a perl bug, or an apt bug?

[*] http://bugs.debian.org/639290



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110825173700.gb5...@elie.gateway.2wire.net

Bug#639214: eglibc: changes to paths concerning crt1.o, crti.o and crtn.o breaks building LLVM Trunk

[Jonathan Nieder]

reassign 639214 general
forcemerge 637232 639214
quit

Hi Marc,

Marc J. Driftmeyer wrote:

> With the most recent changes of moving the object files under
> /usr/lib/x86_64-linux-gnu/ the linker to build Clang/LLVM breaks.
>
> A workaround is to add symlinks for crt1.o, crti.o and crtn.o back
> under /usr/lib.

>From /usr/share/doc/libc6/NEWS.Debian.gz:

  Starting with the eglibc package version 2.13-5, the libraries are
  shipped in the multiarch directory /lib/$arch instead of the more
  traditional /lib. Similarly the includes are now shipped in
  /usr/include/$arch instead of the more traditional /usr/include.

  The toolchain in Debian has been updated to cope with that, and most
  build systems should be unaffected. If you are using a non-Debian
  toolchain to build your software and it is not able to cope with
  multiarch, you might try to pass the following option to your
  compiler:

-B/usr/lib/$arch -I/usr/include/$arch

Does clang support similar options?

See also http://llvm.org/bugs/show_bug.cgi?id=6541 which suggests to
me that upstream is interested in out-of-the-box support for the new
paths.

Reassigning to "general" and merging with the relevant bug, since this
is far from a libc-specific problem.  See [1] for some background.

Thanks and hope that helps,
Jonathan

[1] http://wiki.debian.org/Multiarch



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110825052559.gb2...@elie.gateway.2wire.net

Bug#631256: eglibc: ftbfs with binutils-gold: "These critical programs are missing or too old: ld"

[Jonathan Nieder]

tags 631256 + fixed-upstream
quit

Jonathan Nieder wrote:

> with minor changes, it builds but the resulting ld.so
> segfaults[*].

Yes!  A build with binutils-gold works now (no segfault).  Using
25ad0df1 ("Bug fixes for longjmp_chk on sparc", 2011-08-22) with
the "Make ld --version output matching grok gold's output" patch
applied.

git clone .../glibc.git
git merge origin/roland/gold-vs-libc
git apply <<-\EOF
diff --git i/posix/Makefile w/posix/Makefile
index 499d53d3..b2003421 100644
--- i/posix/Makefile
+++ w/posix/Makefile
@@ -208,6 +208,7 @@ bug-regex23-ENV = LOCPATH=$(common-objpfx)localedata
 bug-regex25-ENV = LOCPATH=$(common-objpfx)localedata
 bug-regex26-ENV = LOCPATH=$(common-objpfx)localedata
 bug-regex30-ENV = LOCPATH=$(common-objpfx)localedata
+bug-regex32-ENV = LOCPATH=$(common-objpfx)localedata
 tst-rxspencer-ARGS = --utf8 rxspencer/tests
 tst-rxspencer-ENV = LOCPATH=$(common-objpfx)localedata
 tst-pcre-ARGS = PCRE.tests
EOF
mkdir build
ln -s /lib/x86_64-linux-gnu/libgcc_s.so.1 .
cd build && ../configure && make && make check



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110823183411.ga24...@elie.gateway.2wire.net

Bug#617759: Thank you (Re: icedove: symbol lookup error: /usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc)

[Jonathan Nieder]

Aurelien Jarno wrote:

>  Fixes
>  symbols resolution with issues with icedove/iceweasel/iceape.  Closes:
>  #617759.

Yes, it works!  (Confirmed the bug again with icedove 3.1.12-1, then
upgraded and the bug went away.)  Thanks, Aurelien.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110823055700.ga10...@elie.gateway.2wire.net

Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems

[Jonathan Nieder]

Quick thoughts.

Sven Joachim wrote:

> +ldfile=$(readlink -e RTLD_SO)
> +# Test if libc is of the same architecture as coreutils
> +# If not, they almost surely have a multiarch system and we can use
> +# the native ELF interpreter
> +if ! $ldfile /bin/true 2>/dev/null; then
> + interpreter=
> +else
> + interpreter=$ldfile
> +fi

Very neat.

[...]
> Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR rather than /lib
[...]
> --- a/debian/debhelper.in/libc.install
> +++ b/debian/debhelper.in/libc.install
> @@ -1,4 +1,4 @@
> -TMPDIR/lib/*.so* /lib
> +TMPDIR/RTLDDIR/*.so* /lib
>  TMPDIR/SLIBDIR/*.so* SLIBDIR
>  TMPDIR/LIBDIR/gconv/* LIBDIR/gconv
>
> diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
> index 18f1800..36d7ee7 100644
> --- a/debian/rules.d/build.mk
> +++ b/debian/rules.d/build.mk
[...]
> - link_name="debian/tmp-$(curpass)/lib/$$rtld_so" ; \
> + link_name="debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so" ; \
>   target="$(call xx,slibdir)/$$(readlink debian/tmp-$(curpass)/$(call 
> xx,slibdir)/$$rtld_so)" ; \
> + mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
>   ln -s $$target $$link_name ;  \

Do I understand correctly that this is this a no-op (to prepare for
patch 5)?

[...]
> @@ -384,6 +404,13 @@ fi
>  #DEBHELPER#
>  
>  if [ -n "$preversion" ]; then
> +if test -L /lib64; then
> + case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
> + amd64 | ppc64 | sparc64 | s390x)
> + remove_lib64_symlink ;;
> + esac
> +fi

If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
wrong value.  Would it be possible to introduce a variable in
debian/rules.d/debhelper.mk so the right value can be cooked in at
build time?

> Subject: [PATCH 6/6] Restore the /lib64 symlink on downgrades
>
> It would be more prudent to prevent the downgrade from happening, but
> if we fail the prerm script, the one from the previous version kicks
> in and succeeds.

Fixed by dpkg commit 9d3ec0f5 (“dpkg: do not fallback to "new-prerm
failed-upgrade" for downgrades”).  Probably that's too new to count
on.

> +#Downgrading from a version with a /lib64 directory to a version with
> +# a /lib64 symlink is extremely dangerous.  We need to blow away the
> +# directory and restore the symlink, otherwise the dynamic linker gets
> +# lost after unpacking the replacing version.
> +
> +ldfile=$(readlink -e RTLD_SO)
> +# Test if libc is of the same architecture as coreutils
> +# If not, they almost surely have a multiarch system and we can use
> +# the native ELF interpreter
> +if ! $ldfile /bin/true 2>/dev/null; then
> + interpreter=
> +else
> + interpreter=$ldfile
> +fi
> +
> +# sync before and after the operation to reduce the danger of hosing
> +# the system
> +sync
> +rm -rf /lib64
> +$interpreter /bin/ln -s /lib /lib64

Maybe it would be possible to mv /lib64 somewhere and loudly let the
admin know about it if it contains anything more than the dynamic
linker.

Remaining problems:

 - disruption to anything running concurrently with the
   upgrade/downgrade.  In the general case, there's nothing one can do
   about this except warn about it.

 - what happens if someone (a) has been trying to load libraries by
   filename in /lib64 or (b) has been installing libraries to /lib64
   and expecting to find them there?

   Most likely, that's not a big deal --- I would expect people to have
   used /usr/local/lib64 or /usr/lib64, but not /lib64.

 - What happens to the /usr/lib64 symlink?

Except where mentioned above, it looks good to me (though I haven't
tested yet).  Thanks!



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110813201419.gb13...@elie.gateway.2wire.net

Bug#637360: backtrace() doesn't work on armel

[Jonathan Nieder]

Aurelien Jarno wrote:

> Backtrace code for ARM EABI has been added in glibc 2.11 [1], and is 
> based on unwind information. -funwind-tables is therefore necessary to 
> get it working, and then backtrace() is fully functional.
>
> I therefore don't see the need to tag this bug as wontfix.

Sure, I probably assumed too much.  Stéphane, does -funwind-tables
take care of your needs?

Thanks, both.



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110811184701.gb2...@elie.gateway.2wire.net

Bug#637360: backtrace() doesn't work on armel

[Jonathan Nieder]

severity 637360 wishlist
retitle 637360 [arm] backtrace() requires unwind information
# unlikely to be fixed any time soon
tags 637360 + upstream wontfix
quit

Hi Stéphane,

Stéphane Glondu wrote:

>   #include 
>
>   int main() {
> void *buffer[100];
> return backtrace(buffer, 100);
>   }
>
> returns 0. It returns with a non-zero status (3 everywhere I've tried
> myself) on all other release architectures.
>
> Is that expected?

I'm surprised it works on mips.  Building with -funwind-tables should
help.

This is a somewhat fundamental limitation, and very hard to work
around.  See e.g. [1] for inspiration if you want to work on it.

Hope that helps,
Jonathan

[1] 
http://www.celinux.org/elc08_presentations/ELC2008%20-%20Back-tracing%20in%20MIPS-based%20Linux%20Systems.pdf



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110810231559.ga11...@elie.gateway.2wire.net

Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems

[Jonathan Nieder]

Aurelien Jarno wrote:

> I don't think we want any manual intervention for this transition. For
> the symlink I would prefer not having /lib64 left, as a lot of configure
> scripts are actually looking to /lib64 to determine random things. Also
> we have just seen that leaving leftover that are not handled by dpkg can
> be a pain years after.

Ok, that's convincing enough.  I'm tempted to suggest (*)

mkdir /lib64.real
symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to
/lib64.real/ld-linux-x86-64.so.2

if this is a chroot:
sync
unlink /lib64
rename /lib64.real to /lib64
sync
else:
ln -s lib64.real /lib64.eglibc-tmp
rename lib64.eglibc-tmp to /lib64

and replacing the /lib64 symlink with a directory on startup in the
non-chroot case, hoping that

 (1) in chroots, hopefully not too much is happening concurrently
 (2) in non-chroots, people reboot from time to time to get security
 updates

But for now, why not always take the "if this is a chroot" branch.
The atomicity part can happen later (when it is reported as a bug or
someone implements it).  If we're lucky, the syncs will stall other
processes long enough to avoid trouble. :)



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110810211315.gb7...@elie.gateway.2wire.net