std library hooks

[Walter Bright]

On 4/15/2012 10:42 PM, Nick Sabalausky wrote:
> "Walter Bright"<newshound2 at digitalmars.com>  wrote in message
> news:jmg9r2$1s3u$1 at digitalmars.com...
>> On 4/15/2012 9:49 PM, Nick Sabalausky wrote:
>>> The link-time "hook" system has such horrid
>>> semantics, diagnostics and compatibility, you're gonne need to document
>>> the
>>> hell out of that if you expect people to actually use it.
>>
>> What's so hard about:
>>
>> "If you want to override the standard library function _d_assertm(),
>> provide your own somewhere in your source code, like this:"
>>
>> extern (C) void __dassertm(ModuleInfo* m, uint linenum)
>> {
>>     ....
>>     printf("I failed\n");
>>     exit(EXIT_FAILURE);
>> }
>>
>> ??
>
> Aside from the cmdline order subtleties,

There aren't any. Have __dassertm in your .o files on the command line, and they 
will have supremacy.

> this is what's bugging me:
>
> 2012/4/15 "Jérôme M. Berger"<jeberger at free.fr>
>>          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).

As Sean mentioned, the solution is for the library version of __dassertm to 
exist in its own .o file. That is not necessary for the user version.