glibc 2.33 gives optimized libraries named search directories

Shipping an optimized shared library creates a deployment problem before it creates a performance opportunity. The library must reach machines that can execute its instructions, while a compatible implementation remains available for machines that cannot. A package containing only the specialized build imposes its processor requirements on every consumer. Keeping separate installations makes the choice an operational responsibility outside the program.

The glibc 2.33 announcement of February 1 introduces glibc-hwcaps subdirectories into the dynamic linker's library search. Libraries under these directories become candidates when the machine satisfies the corresponding capability requirements. An installation can therefore retain its default library and place additional implementations beneath named processor levels.

I value C partly because its practical role extends beyond the language's syntax into platform interfaces. This change belongs to that part of the system. Application source need not express a processor-selection policy for every library dependency. The loader can make the selection using a packaging convention shared by the library provider and the runtime.

A directory expresses a machine requirement

The release initially names x86-64-v2, x86-64-v3, and x86-64-v4 for x86-64. These are the vendor-independent microarchitecture levels in the x86-64 psABI supplement. Other supported names include power9 and power10 for little-endian 64-bit PowerPC, and z13, z14, and z15 for s390x. The names describe the requirements under which the loader may consider a library, rather than an application's estimate of the fastest processor brand.

A schematic installation for a library called libexample.so.1 can place the baseline file directly in a search directory and a specialized file below it:

/opt/example/lib/libexample.so.1
/opt/example/lib/glibc-hwcaps/x86-64-v3/libexample.so.1

The example assumes /opt/example/lib is already part of the relevant library search path. Merely creating the directory does not establish that search path. The new convention adds alternatives underneath a directory the loader is considering. It does not remove the need to arrange ordinary discovery of the library.

Both files must implement the interface expected by the consumer. Directory selection cannot compensate for an incompatible function signature or object layout. That follows from the nature of the mechanism. The loader chooses a shared object before the consumer calls into it, and a different implementation must remain a substitute for the dependency the program requested. A processor-specific build is useful here when specialization preserves that contract.

This places responsibility at a useful boundary. The library author decides which implementations to provide. Packaging records their machine requirements in directory placement. The runtime determines which of those requirements the current system meets. A program can continue to request the library without duplicating the platform taxonomy in its own startup code.

The search list avoids combining the new names

The 2.33 loader implementation makes an important distinction between the new directories and the older capability search. It explicitly excludes glibc-hwcaps entries from the legacy power-set construction. The new entries are individual directory names. The older code constructs combinations of capability names.

That distinction matters when reasoning about installation layout. Independent capability components can lead to combinations of subdirectories. A named processor level instead represents a defined capability grouping, so the package need not mirror every possible combination of individual features. In the implementation, the new entries receive the glibc-hwcaps prefix and a trailing slash before they enter the result list.

The code also computes priorities for the entries. Prepended directories come first, followed by active built-in directories after masking. It then sorts the priority records by name for lookup. The existence of a name-sorted structure should not be mistaken for an alphabetical preference among processor levels. Priority is stored as separate data before that sort.

There are therefore two different questions in the source. One concerns which capability names are active. The other concerns their precedence in lookup. Keeping these questions separate makes the implementation easier to interpret and explains why a directory's spelling alone is insufficient to infer selection order. The runtime uses its configured and detected capability information when constructing the candidates.

I prefer this explicit installation model to an undocumented assumption that every machine in a deployment has the same instruction set. The baseline library remains a concrete file with a concrete purpose. Specialized builds can be introduced without silently redefining the minimum machine requirement of that file.

Compatibility still constrains the deployment

The announcement also changes behavior for dlopen in statically linked programs. Such programs no longer load alternative implementations from HWCAP subdirectories and use the default implementation instead. That limitation belongs in the description of the feature because the existence of an optimized library on disk does not imply every loading mode selects it.

The release notes announce a future withdrawal of several older lookup conventions, including tls subdirectories, the platform-name directory, and legacy AT_HWCAP search. They direct applications toward glibc-hwcaps. As of this release, that is a stated migration direction. It should not be confused with a claim that all those older paths have already disappeared in 2.33.

For a package maintainer, the immediate consequence is a new installation choice. A baseline implementation can remain usable across the intended population of machines, with extra builds provided for selected supported levels. The extra files also create maintenance work. A security fix or ABI correction must reach every implementation that may be selected, because the optimized copy is executable library code in its own right.

The loader's choice establishes eligibility, not a performance result for a particular workload. A named level can permit different generated instructions, but the directory mechanism says nothing about whether a given algorithm benefits from them. Its contribution is that an eligible build can be selected and distributed coherently. The implementation still determines what work those instructions perform.

The accompanying loader diagnostics help expose this part of execution. glibc 2.33 adds a --help option that reports usage and library search information. That is relevant to a deployment with multiple copies of the same library name, where the path considered by the loader is part of understanding which implementation the process can use.