On 4/15/2012 10:42 PM, Nick Sabalausky wrote:
"Walter Bright"<newshou...@digitalmars.com> wrote in message
news:jmg9r2$1s3u$1...@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"<jeber...@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.
