errno definition broken in non-threaded code

Jim Blandy jimb at
Fri Nov 17 08:05:52 UTC 2006

Mike Frysinger <vapier at> writes:
> so, would the correct fix here be:
>  - if thread support is disabled, export errno symbols and do not define the 
> location functions at all requiring all internal uClibc references to go 
> through the GOT to get at the errno location
>  - if thread support is enabled, do not export the errno symbols and allow 
> internal hidden references to it from the location functions

I've gone fuzzy on the details, but I think my favorite would be:

- If thread support is disabled and libc is statically linked, export
  errno symbols.  (I thought I saw assembly code somewhere calling the
  location functions, so maybe they can't go, but that's fuzzy now

- Otherwise, keep errno hidden and have all external accesses go via
  location functions.

I suspect the difference in code size between location functions and
GOT references is minimal, and because I doubt the speed has any
impact on real applications.  If those suspicions are right, why not
have ABI compatibility?

> so the implied question i guess is, how much ABI compat do we care about 
> between threaded and none threaded builds ?


More information about the uClibc mailing list