Do not use ThreadLocal $errno because this symbol is GLIBC_PRIVATE.

[felixvf]

No description provided.

[ysbaddaden]

Please provide background for this claim, what historical glibc versions we're breaking, ...

[felixvf]

@ysbaddaden, when running this script

#!/bin/sh

echo >demo.cr 'puts "errno=#{Errno.value}."'
crystal build demo.cr
./demo
LD_DEBUG=bindings ./demo 2>&1 | grep -i errno

on a system with glibc-2.26, you may get this output:

errno=0.
      6798:     binding file /lib64/libpthread.so.0 [0] to /lib64/libc.so.6 [0]: normal symbol `errno' [GLIBC_PRIVATE]
      6798:     binding file /lib64/libpthread.so.0 [0] to /lib64/libc.so.6 [0]: normal symbol `__h_errno' [GLIBC_PRIVATE]
      6798:     binding file /lib64/librt.so.1 [0] to /lib64/libc.so.6 [0]: normal symbol `errno' [GLIBC_PRIVATE]
      6798:     binding file ./demo [0] to /lib64/libc.so.6 [0]: normal symbol `errno' [GLIBC_PRIVATE]
errno=25.

The important aspect is binding file ./demo [0] to /lib64/libc.so.6 [0]: normal symbol `errno' [GLIBC_PRIVATE]. It shows that the compild output references the errno symbol. However, the symbol errno is considered GLIBC_PRIVATE. As of https://groups.google.com/forum/#!topic/uk.comp.os.linux/PX3rstGtZRQ, this means that the the symbol errno is only for the purpose of communicating with other parts of the GNU C library. This means that referencing the errno symbol from programs or libraries not being part of the GNU C library is an error.

There are standard packaging tools which enforce that binaries to be packaged do not reference symbols they shall not reference. This means that current Crystal-generated binaries which access Errno (including crystal itself) do not pass this check and therefore cannot be packaged.

This pull request fixes that situation.

[ysbaddaden]

Thanks for the details. _errno_location seems to have been introduced in glibc 2.2.5 (released in 2002), so we can hopefully use it without breaking anything.

One less ThreadLocal.

[sdogruyol]

Thank you @felixvf 👍