> I did notice it doing that twice!  However my timestamped trace of
> the startup does show that most of the time between one dlopen()
> returning and the net one starting is actually spent within
> ld.elf_so doing 'lazy' fixups.

You might as well have said there `most of the time spent in ld.elf_so
is spent doing 'lazy' fixups'.  The reality is that most of the
startup time is in Mozilla, not ld.elf_so.

> Do they actually DTRT?
> For instance there are references within libc to (IIRC) fseek, which
> only has a week definition there....

That's exactly why the weak aliases were added in the first place --
the library calls (e.g.) _fseek(), and fseek() is an alias to it
that's exported.  In this way, the internal calls are theoretically
guaranteed to go to the right routine.

(fseek() is a bad example, though, in that it's not aliased, and it's
only used by libc in the implementation of rewind().)

> Yes, I'd noticed that weak symbols go through the DAGs, what I hadn't
> worked out (yet) is why the DAG list contains repeated entries for the
> same library.

That's a more interesting question.

> Nor whether it is necessary (ever) to look at the
> same library twice during a symbol search.

It's not, in principal.  However, the previous attempt to prevent that
was broken.

> I used to build a shared library by compiling it as one big piece.
> That way it was possible to get all the internal references to be
> to local symbols and fixed up by PC relative calls by the compiler.
> Setting it up for libc would be a little tedious though.

And, unfortunately, it would be a tedious waste of time, because it
wouldn't work.  If the symbols are exported, calls to them would still
go through the PLT and have to be fixed up, even if they're in the
same module.