ricaljasan | 25 Oct 07:08 2014

Non-volatile errno

Chapter Error Reporting, section Checking for Errors defines errno as:

 <at> deftypevr {Variable} {volatile int} errno

and continues on to say:

Since  <at> code{errno} is declared  <at> code{volatile}, it might be changed
asynchronously by a signal handler; see  <at> ref{Defining Handlers}.

but errno is not declared volatile.  On a system built with 2.19:

$ find /usr/include -name errno.h | xargs grep 'volatile.*errno'
$ find /usr/include -name errno.h | xargs grep 'int errno'
/usr/include/errno.h:extern int errno;

In the current git:
$ find . -name errno.h | xargs grep 'volatile.*errno'
$ find . -name errno.h | xargs grep 'int errno'
./stdlib/errno.h:extern int errno;

I assume extern is taken for granted since I don't see any other
variables declared extern in the manual.

Also, I'm not sure about the correctness of the subsequent description.
 Is it true that a signal handler can asynchronously change errno
*because* it is declared volatile?  If so, does removing the volatile
declaration warrant removing the comment about signal handlers, or
should that be reworded to say something else?

(Continue reading)

Andrei Borzenkov | 16 Oct 19:46 2014

Incorrect timezone offset with current Russian rules - tzdata or glibc bug or normal?

I hit strange problem which looks like a bug and actually caused
serious problem due to different interpretation of current timezone

Current tzdata correctly - as far as I can tell - defines time today as
UTC-4 with summer time inactive:

/etc/localtime  Sat Mar 26 23:00:00 2011 UT = Sun Mar 27 03:00:00 2011 MSK isdst=0 gmtoff=14400
/etc/localtime  Sat Oct 25 21:59:59 2014 UT = Sun Oct 26 01:59:59 2014 MSK isdst=0 gmtoff=14400
/etc/localtime  Sat Oct 25 22:00:00 2014 UT = Sun Oct 26 01:00:00 2014 MSK isdst=0 gmtoff=10800
/etc/localtime  9223372036854689407 = NULL
/etc/localtime  9223372036854775807 = NULL

But the valule of variable "timezone" (man timezone(3)) is set to
UTC-3 ...

bor <at> opensuse:~/tmp/sapttzz> ./sapttz 
Name of local time zone:
   no info (=TZ)

Technical description of local time zone:
   UTC time +10800 sec

Daylight Saving Time at the current/given date is:

where offset is computed as simply

    printf("   UTC time %+ld sec\n",- (long int)timezone);
    if(tm->tm_isdst == 1)
(Continue reading)

Michael Brunnbauer | 14 Oct 14:52 2014

glibc 2.20 make install

hi all,

I remember reading that upgrading glibc with make install is not a good idea
or "not supported". What is the correct way of upgrading glibc?

make install worked for me so far as some basic tools like rm, mv and ln are 
static. But when upgrading from glibc 2.17 to glibc 2.20, I had to use a 
statically linked msgfmt and I had to revert this change from the Changelog:

   * Makerules (make-shlib-link): Use rellns-sh to get relative name

I hope that either there is an easy way to avoid such problems or that the
developers try to keep "make install" simple - so that it can be used for
upgrading. It has worked for me for many years.


Michael Brunnbauer


++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@...
++  http://www.netestate.de/
(Continue reading)

ricaljasan | 5 Oct 08:30 2014

Questions on Documentation and NSS

Does documentation follow the 79-column style?  The style in
manual/nss.texi (and most other manual/*.texi files) appears to lean
towards 72 columns, although there are a handful of lines where it goes
over by a few characters. This isn't including  <at> node,  <at> item, etc., lines
which consistently go much longer on a single line, despite Texinfo
allowing '\' line breaks (tested, no errors, node references remained
correct).  I'll stick with 72 because of the respect-the-locals
philosophy, but that brings up a couple other questions: should I bother
bringing rogue 73+ character lines back to <73 when I come across them
or would changes like those be considered too superfluous?  Occasionally
I would add a character to a line and that would cause an entire
paragraph to shift, causing the diff to appear much more substantial
than it really was.  I left 73-column lines in those cases.  Aside from
preventing diff noise (a term I believe I heard on the list at some
point), I couldn't find any coding guidelines which stated documentation
source should be 72 columns instead of the glibc 79.

Next question: is it "the 'Name Service Switch'" or "Name Service
Switch"?  For instance, the second paragraph of the chapter states, "The
GNU C Library... calls this scheme `Name Service Switch'".  To me, "the
`Name Service Switch'" sounds more appropriate.  I do contrast that with
the acronym, NSS, however.  When I read the initials, I usually don't
prefix the phrase with "the" because I read it as the three letters,
"en-ess-ess", and it acts as its own entity for the most part.

I think the key difference to me is the use of "switch" as a noun in the
sense of: 7) a turning, shifting, or changing. (Dictionary.com)  I just
happened to be reading RFC 1034 the other day and when I finished it and
started skimming the references, I realized some of the historical
significance of the Domain Name Service - I saw a handful of earlier
(Continue reading)

Petr Silhavy | 2 Oct 12:14 2014

glibc-2.20 seteuid()/setegid() : Function not implemented

Hi list,
after I installed glibc-2.20 as my primary libc, I got error messages 
from all utilities calling seteuid/setegid e.g. :

# xterm &
xterm: setegid(0): Function not implemented
xterm: seteuid(0): Function not implemented
xterm: seteuid(0): Function not implemented
xterm: setegid(0): Function not implemented

When I installed glibc-2.20 as primary on systemd container/virtual host
on the same system - no problem here .

Any hints, ideas, patches ? TIA

Linux 3.16.3
gcc (GCC) 4.9.1
GNU ld (GNU Binutils) 2.24
GNU Make 3.82
Built for i686-pc-linux-gnu

I tried following configure options with no difference to 
"Function not implemented"

../glibc-2.20/configure --prefix=/usr --enable-kernel=2.6.0 --with-headers=/usr/src/linux-3.16/usr/include
../glibc-2.20/configure --prefix=/usr --enable-kernel=3.5.0 --with-headers=/usr/src/linux-3.16/usr/include
../glibc-2.20/configure --prefix=/usr --enable-kernel=2.6.0
../glibc-2.20/configure --prefix=/usr

(Continue reading)

Daniel Goertzen | 29 Sep 21:54 2014

Fwd: libpthread.so illegal cpuid on 486

After a long struggle trying to get glibc-2.19 running on my 486
embedded systems, I discovered that libpthread.so was invoking the
"cpuid" instruction.  This instruction is not present on most 486 cpus
and will cause the program to fail with "Illegal instruction."

My system used to work fine with glibc-2.17; it looks like the problem
arrived with the new lock elision stuff.  I tried building with
--disable-lock-elision but the cpuid-based checks are still performed.

Am I doing something wrong?
Is this a bug?
Is glibc leaving the 486 behind?


Steve Ellcey | 24 Sep 18:18 2014

Parallel builds of glibc / PARALLELMFLAGS

I have a question about parallel builds of glibc.  Someone asked me about 
PARALLELMFLAGS and I was trying to understand what the current situation
is.  It looks like you need to set this to something like "-j 4" to do
parallel builds but in manual/install.texi there is this statement that
seems to contradict that idea:

| If you want to run a parallel make, simply pass the  <at> samp{-j} option
| with an appropriate numeric parameter to  <at> code{make}.  You need a recent
| GNU  <at> code{make} version, though.

So, is using PARALLELMFLAGS the 'correct' way to do parallel builds (in which
case I will submit a patch to update install.texi) or should -j flags be
getting automatically passed down to sub-makes, in which case I think there is
a bug in the makefiles that is preventing this and we should figure out
how to fix it.

Steve Ellcey

Joël Krähemann | 24 Sep 01:06 2014

automatic memory allocation leaks like mad


How to fix this?


my application uses about:

23442 joel      20   0  255g 445m  12m S 384,3  5,7   2:46.58 ags

I'm not sure but me really believe ags hangs because of a memory leak.
Any ideas?

please let me know

Mildred Ki'Lya | 19 Sep 12:51 2014

fclose blocks until a fread call in another thread returns


I'm having a problem with glibc 2.20. I have a program with multiple 
threads (two are running when I have the problem). The main thread 
contains an event loop. The other thread is just a popen call to nmap, 
and a read call that blocks until nmap has finished.

On the main thread, at some point, I open a file, write some content, 
and then close the file.

The problem is that the main thread is always blocking until the nmap 
thread finishes reading the popen pipe.

Running the application with gdb, I found the following stack traces:

main thread:

#0  0x00007ffff73d8b2b in __lll_lock_wait_private () from 
#1  0x00007ffff7359b25 in __GI__IO_un_link.part.1 () from 
#2  0x00007ffff734dad5 in fclose <at>  <at> GLIBC_2.2.5 () from /usr/lib/libc.so.6

popen thread:

#0  0x00007ffff73bf55d in read () from /usr/lib/libc.so.6
#1  0x00007ffff73596c0 in __GI__IO_file_underflow () from 
#2  0x00007ffff735a6ec in __GI__IO_default_xsgetn () from 
(Continue reading)

Mark Hills | 18 Sep 12:03 2014

LD_PRELOAD functions are called before _init

I am finding that when LD_PRELOAD is used, calls to symbols are commonly 
(incorrectly?) invoked before the _init function.

See the minimal example below; where fopen64() is invoked before the 

This makes it impossible to use _init as a 'constructor'. Am I expecting a 
guarantee that does not exist?

In practice, my problem is this completely prevents wrapping of fopen() in 
a commercial application:

* this application provides a new malloc() by linking against 

* the new malloc() function takes a lock and makes a call to fopen()

* without the constructor, our implementation of fopen() must call 
  dlsym(), but this recursively calls malloc() and deadlocks

Is there are better practice to 'initialise' this, or is some bug mangling 
the expected ordering?

This is on Scientific Linux 6.5 (a derivative of RedHat 6.5, see version 

Advice appreciated -- thanks.


(Continue reading)

Steve Ellcey | 12 Sep 01:23 2014

Problem running make check?

Has anyone seen these errors when running 'make check' on glibc?

make[2]: *** No rule to make target
needed by `tests'.

make[2]: *** No rule to make target
needed by `tests'.

I am not sure if it is related or not but when building glibc I got these
warnings from perl:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

I think that after these errors my 'make check' hangs.

Steve Ellcey