std library hooks

["Jérôme M. Berger"]

H. S. Teoh wrote:
> I made a one-function library called mylib.a, that exports a single
> function 'mylibfunc'. Then I wrote some code in aux.c that calls
> 'mylibfunc', and then in main.c, I define a different version of
> 'mylibfunc' along with main(). Here's the result of various orderings of
> the linker command-line (each .c file is compiled with gcc -c
> beforehand):
> 
> 1) ld mylib.a aux.o main.o
> 	Works, main's version of 'mylibfunc' is picked up
> 
> 2) ld aux.o mylib.a main.o
> 	Fails: ld complains that 'mylibfunc' is multiply defined
> 
> 3) ld aux.o main.o mylib.a
> 	Works, main's version of 'mylibfunc' is picked up
> 
> 4) ld main.o aux.o mylib.a
> 	Works, main's version of 'mylibfunc' is picked up
> 
> So here's my understanding of what happens:
> 
> For (1), ld doesn't even care about mylib.a because there are no
> unresolved symbols to resolve yet. Then it sees aux.o, which has
> unresolved reference to 'mylibfunc', then it sees main.o, which resolves
> this symbol, so it finishes successfully.
> 
> For (2), ld sees aux.o first, which has unresolved symbol 'mylibfunc',
> so it searches mylib.a next, and finds 'mylibfunc' in mylib.a, so it
> links that in. Now when it sees main.o next, it sees 'mylibfunc' again,
> and complains that it's already been defined.
> 
> For (3), ld sees aux.o first, which references unresolved symbol
> 'mylibfunc', then it sees main.o, which defines 'mylibfunc', so now all
> symbols are resolved. So when it sees mylib.a next, it does nothing 'cos
> there are no more symbols to resolve. So this leaves us with main's
> version of 'mylibfunc' linked.
> 
> For (4), ld sees main.o first, which exports 'mylibfunc', so when it
> sees aux.o next, which references 'mylibfunc', it resolves it to main's
> version of 'mylibfunc'. Then it sees mylib.a but does nothing because
> all symbols have already been resolved.
> 
> Conclusion: defining your own version of library functions work... if
> you link the library after your own version. If the library's version
> gets picked up first, the linker will complain about duplicate symbols.
> 
	In addition to what you have just said, there is another subtility.
If either main.o or aux.o references another symbol mylibfunc2, and
if both mylibfunc and mylibfunc2 are provided by the *same* object
file inside mylib.a, then when the linker pulls in mylibfunc2 it
will *also* pull in mylibfunc and complain about a duplicate
definition. This also depends on your version of the compiler and
linker, and on the compilation options (I believe the
-ffunction-sections gcc option makes the issue disappear for example).

		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120415/23bc85ec/attachment-0001.pgp>