Hi,

> Actually, it did pick a shared __sF symbol as a result of the dynamic libc
> in your example, even though the symbol was physically located in the
> binary. 

Well, if with "it picked a shared __sF symbol" you are trying
to say that it arranged things so that the shared library could
actually share the symbol with the main program, yes, I agree.
And that's pretty much, what I'd expect.

> When ld(1) is binding symbols in a binary, it will put symbols needed by
> libraries (in the case of your program, -lc, implicitly added by gcc) in the
> dynamic symbol section of the binary.  These can then participate in the
> ld.elf_so linking process.  (In the case of __sF, BSS space got allocated
> too, so the symbol actually ended up in the binary rather than libc.so, both
> with and without libc.a.)

IMHO it's a bug for ld to not put all the (external) symbols
defined in the binary in the dynsym/dynstr sections.  

> However, what we're dealing with in this thread are "static" binaries --
> that is, binaries that have the ability to do dynamic loading, but which
> contain no dynamic references to anything but the dynamic loader itself.
> So, the resultant program *must not* have a reference to libc.so (since this
> is exactly what the proponents of "static dlopen()" propose).

Yes, of course you need something describing the symbols which
are defined within the binary.  However, there is no need for
the binary to have a reference to libc.so.  It's sufficient if
the binary's dynamic symbol table provides information for all
symbols defined within this binary.

With our current system, there is a subtle difference between
shared objects against which a program is linked and those
which get dlopen()ed.  For the latter ones, you cannot
overwrite symbols in the main program used by the shared
object.  Actually, you can, if the symbol in question is also
defined in a shared object against which the program is linked.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     Wolfgang Solfrank, TooLs GmbH 	+49-228-985800