we don't/wont have these any longer

Our .so numbers are not usually this high and we typically don't have major/minor components -- e.g. ours is /lib/libc.so.7. Note also that this example is in /lib, not /usr/lib. /usr/lib/libc.so is a symlink to that, and is what is actually used in the linking process.

I'm not sure there's value in specifying mmap here, IMO it's sufficient to mention that rtld loads the shared libraries when the program is executed.

.a for PIE binaries is something that we still need to resolve

on modern ISAs this isn't really true, it's primarily i386 where this is an issue

There are only two classes of libraries, so this seems a bit of an odd phrasing.

this isn't really true, the index is generally created by passing the s flag to ar. ranlib is really only of historical interest

Note that this option is documented as deprecated and will be removed.

During static linking only the necessary object files are linked in, not the whole library. Perhaps "all necessary library code" would be better?

As far as I understand, profiling libraries are somewhat obsolete in FreeBSD. For example, pmcstat(8) doesn't need them. However, they still exist so they need to be described here.

More advantages: a namespace per shared library is available via hidden visibility, allowing multiple compilation units in a library to share things without making them available to other libraries; it is possible to load libraries dynamically via dlopen(3).

Another disadvantage: calls across shared libraries are also slightly slower and cannot be inlined (not even with link time optimization).

Does FreeBSD have a supported configuration without shared libraries? I expect no?

... linked against a static library, ...

As written, it's not clear what ld.so does and what rtld does; they are both described as loading the libraries when the program is executed.

This section does not explain the difference between PIC and relocatable code.

Are -fpic and -fPIC literally identical? If so, pick one, and don't mention the other.

The common way of working is to use -fPIC only; on certain architectures, -fpic generates slightly more efficient code if the resulting file is smaller than an architecture-dependent size. I'd say -fpic need not be mentioned here.

What should perhaps be mentioned is -fPIE which generates position-independent code for executables. That is, it makes the code position-independent but still assumes that it will be linked into an executable and not a shared library. This might be slightly more efficient.

it can be inefficient with both disk space and memory usage during execution

They aren't built by default any longer, so there's no point in documenting them for 14.

I'd say either "version number" or "library version number"
"library number" to me suggests that there's some sort of ID number for the library, like libc is library 1, libz is library 2, etc.

We probably need to document symbol versioning, too

s/program/library/?

No, so I don't think we need to say "on systems that support it."

-shared is the default and the only case I am aware of that it would be necessary is if some CFLAGS contained -static and it needed to be overridden.

Should it be "linked dynamically"?

Why?

Good catch! :)

For reference of options I think. I can remove it, if necessary.

Is this incomplete? I think I don't understand what this is meant to show.

Otherwise you are saying, "when it is linked, it will be linked".

The choice is yours, but it does not seem clearly relevant to me.

In a former version of this differential there where profiling versions descriptions, which was removed a while ago in FreeBSD.

I would suggest to rewrite

Typically, a library will have a number of variants:

to

A library has the following naming convention: