This is the mail archive of the
mailing list for the glibc project.
libc add-ons changes
- From: Roland McGrath <roland at redhat dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: Mon, 27 Feb 2006 23:51:54 -0800 (PST)
- Subject: libc add-ons changes
I've checked in some makefile and configure changes to how add-ons work.
I've nominally tested things, but there are probably some loose ends.
Please keep an eye out for new oddities in your builds.
I have not yet updated maint.texi; if anyone wants to lend a hand with
that, it would be more than welcome. For maintaining and using add-ons,
these are the differences:
* Add-ons no longer need to be unpacked inside the libc source tree. An
add-on directory can be located anywhere. In the --enable-add-ons option
you can list absolute directory names, or names relative to the source
directory (I expect this will be the most common,
e.g. ../glibc-ports-2.4), or names relative to the build directory.
For those maintaining and distributing add-on tarballs, they can now
contain a subdirectory called glibc-foobar-VERSION or whatever, in the
* An add-on is not automatically added as a subdir in the libc build.
To unconditionally add subdirs, an add-on's configure fragment must
set the libc_add_on_subdirs variable to a list of subdirectories.
This list can include . as a member to treat the add-on directory as a
libc build subdir, as in the old style; libidn/configure.in does this.
Build subdirs (still) may instead be included via sysdeps/.../Subdirs files.
(This is how nptl works.)
* An add-on need not have a configure fragment. An add-on that contains a
sysdeps/ directory tree does not need also have a configure fragment if
it has nothing to do. Its sysdeps/ directories will still contribute to
the search list, and any sysdeps/.../configure fragments will be run.
For --enable-add-ons=yes, it will look for any subdirectories that
contain either a sysdeps directory or a configure fragment.
Each add-on is automatically searched for sysdeps/*/preconfigure fragments.
This matches what the ports add-on's configure fragment used to do.
These fragments are intended only to canonicalize $machine and $base_machine,
so that the sysdeps search list will work. This is now implicit so that
add-on ports can contain nothing but the sysdeps/ directories for the port.
* configure fragment must set libc_add_on_canonical. If an add-on has a
configure fragment, it must set the variable libc_add_on_canonical to
empty or to something. This is the canonical name of the add-on, that's
used as a possible subdirectory in the sysdeps tree of other add-ons;
e.g. "linuxthreads", regardless of what the name of the add-on directory is.
* For each add-on that supplies sysdeps directories, its top-level
directory is automatically added to the -I list (immediately after
sysdeps directories). This is so that #include <sysdeps/...> in add-on
code can work to find other code in the add-on.
Note that this means that an add-on <sysdeps/foo.c> can no longer use
#include <sysdeps/foo.c> to get the main source tree's file by the same
name. Instead, it can be done with some machinations using #include_next.
There are several examples of this in nptl that I changed.
* sysdeps/generic directories in add-ons are no longer used.
The -I switch for the top-level add-on directory means that
headers can go there instead of in a sysdeps/generic subdirectory,
and still be found by compilations in whichever build subdir.
I've probably forgotten something else I should mention.