Oh, please don't take it that way.
The above case you can KNOW at link-time. Your linker can (and will)
trivially notice that "uhhuh, I have malloc defined both in the body of
the program AND the library, but the other reference is weak, so I'll use
the program version". And then you just encode that information in the
startup code, and you can STILL use a pre-linked library without having to
do a full re-link (you have to relink only the known weak references to
malloc - you don't have to do the full job).
And the above only happens when there _are_ clashes. Which should
hopefully not be that often with any normal programs.
What I was talking about is what happens if a program has a function
called "mmap64()" and the library does NOT. Now the linker will decide
that there are no clashes, and will not create any fixup code - and we'll
use the prelinked libc.so without even checking anything. Right?
Now, we upgrade libc to a new minor version. This minor version is also
pre-linked, but it now has a weak symbol mmap64() because it is starting
to use the new mmap capabilities. Now let us further assume that the
library itself references that weak mmap64 symbol somewhere..
Now, with the optimized pre-linking stuff, the old binary will NOT notice
that we have clash, and the library reference will use the internal weak
mmap64 instead of the object file strong mmap64. And my argument is that
that is actually the correct behaviour (it's _different_ from what happens
now as far as I can tell, but definitely not wrong).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/