std library hooks

[Nick Sabalausky]

"Walter Bright" <newshound2 at digitalmars.com> wrote in message 
news:jmgc33$1vjq$1 at digitalmars.com...
> 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.
>

Manu showed that, at least for ld, the order does matter. But if DMD always 
passes druntime to the linker last, and doing so doesn't conflict with any 
other ordering requirements, then that's good enough for me.

>> 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.

1. Is that currently happening?

2. Doesn't it need to be in its own separate source file to end up in a 
separate object file?

3. If so, wouldn't keeping each druntime function in a separate source file 
make maintaining druntime a pain?