Gnu Toolchain/GLIBC/Modifying GLIBC
This page was originally created by Ryan S. Arnold aka RandomTask.
The GLIBC configure stage revolves around the sysdeps directory tree and search paths. The configure script is responsible for generating the search path from the layout of the sysdeps directory tree and the directives of Implies and Subdirs files in that tree.
The configure stage is also responsible for verifying system dependencies and related toolchain dependencies. For instance, particular add-on configure fragments may be necessary to detect the presence of compiler options like secure-plt or decimal-float support.
Sysdeps and search paths
The search path. What's included and what's not. How do I get it to pick up other files? See below.
By default the GLIBC configure script locates ALL directories in the sysdeps tree and puts them in a search order based upon depth-precedence. The deeper the directory the earlier in the search order it exists.
An 'Implies' file is only to be used in order to pick up a directory with depth lower than the default before the default is picked up. If you include an Implies file needlessly you may find that the search order gets messed up and the 'generic' case gets picked up before an override with greater depth that you want to take precedence. This is due to how the configure script interprets the 'Implies' file. When it sees a target it groups all matching directories that haven't already been added to the search order together, for instance 'powerpc' matches the following directories, so an Implies 'powerpc' would group all of them together in the search order:
sysdeps/powerpc dfp/sysdeps/powerpc sysdeps/unix/sysv/linux/powerpc dfp/sydeps/unix/sysv/linux/powerpc
Here's an example given the following sysdeps directory structure:
sysdeps/powerpc dfp/sysdeps/powerpc sysdeps/powerpc/powerpc64/ sysdeps/powerpc/powerpc32/ sysdeps/unix/sysv/linux/powerpc dfp/sysdeps/unix/sysv/linux/powerpc
The default search order should be:
dfp/sysdeps/unix/sysv/linux/powerpc sysdeps/unix/sysv/linux/powerpc sysdeps/powerpc/powerpc64 sysdeps/powerpc/powerpc32 dfp/sysdeps/powerpc/ sysdeps/powerpc
If you were to spuriously add the following Implies file:
You'll unwittingly affect the default search order because when you imply "powerpc" all matching "powerpc" directories will be inserted into the search order following the location of the Implies file, not just the directory you intended, e.g.
dfp/sysdeps/unix/sysv/linux/powerpc dfp/sysdeps/powerpc sysdeps/powerpc sysdeps/unix/sysv/linux/powerpc sysdeps/powerpc/powerpc64 sysdeps/powerpc/powerpc32
As you can see, this disrupts the intended search order because the generic 'sysdeps/powerpc' is picked up before the 64-bit specific overrides in 'sysdeps/powerpc/powerpc64'.
The proper thing to do is to not use the Implies file at all and let the default depth precedence pick up the dfp/sysdeps/powerpc directly and emplace it before sysdeps/powerpc but after sysdeps/powerpc/powerpc64 and sysdeps/powerpc/powerpc32.
The 'Subdirs' file is used in the sysdeps directory tree in order to include a path outside of the sysdeps tree in the search order. For instance, given the following tree:
sysdeps/powerpc/ sysdeps/powerpc64/ sysdeps/powerpc32 sysdeps/unix/sysv/linux/powerpc dfp/ dfp/sysdeps/powerpc dfp/sysdeps/unix/sysv/linux/powerpc
The 'dfp/sysdeps' directory is considered 'in' the sysdeps directory tree so everything within it is included in the search order. The naked 'dfp/' directory is NOT in the sysdeps tree so it is not included in the search order. Adding a Subdirs:dfp directory to 'dfp/sysdeps/dfp' tells configure that the 'dfp/' directory contains source code, that it should be added to the base 'subdir' variable and processed because it has source files.
NOTE: If you need a directory outside of the sysdeps tree processed by the GLIBC make system you need to have an Implies file in the sysdeps tree point to it.
Overriding glibc base files
Use sysdeps over rides and put a Makefile deep in sysdeps
Making an add-on
what's the add-on name? what's the library name? (see below) Take advantage of the sysdeps search path and add a sysdeps directory to your add-on directory.
A library by any other name...
when the library name is different than the add-on name (i.e. libpthread.so vs. nptl).
<add-on>/ vs. <add-on>/sysdeps/<library>/
When does one put code in <add-on>/ vs. <add-on>/sysdeps/<library>/ where the library name is different than the add-on name?