Use of varargs does not work in GDC unless the necessary symbols from gcc.builtins are imported via std.stdarg. This check happens in
void d_gcc_magic_module(Module *m)
in d-builtins2.cc
This means that Tango (and all other runtime libraries for D) needs to have std.stdarg, even if this leads to an obvious conflict if one is to try to install two such libraries at the same time (Tango and Tangobos is a typical example that is affected by this.)
I can see no reason why gcc.builtins (which also is hardcoded into the magic function above) should be the only required module to have varargs working. An alternative would be adding tango.core.Vararg, but that would be an equally broken solution.
Another solution proposed by Bommel, was that the dependency on gcc.builtins could also be removed, by using a pragma to register the required symbols with the compiler. Probably more work though.
Comment #1 by darrylbleau — 2008-03-26T18:14:27Z
Alternatively, one could allow the stdarg import to come from
somewhere else, something like 'gcc.stdarg' might be a good fit.
That would be a fairly trivial change, just changing the line:
else if (md->packages->dim >= 1 && !strcmp( ((Identifier *)
md->packages->data[0])->string, "std" ))
To also strcmp for "gcc" would allow for std.stdarg, gcc.stdarg,
std.c.stdarg, or gcc.c.stdarg, which seems reasonable and would be a
very simple way to resolve this problem without introducing pragmas or
some other (though possibly more flexible) complex solution.
Comment #2 by fawzi — 2008-04-01T07:24:06Z
I was able to remove the issue with tango and tangobos removing the (unnecessary) import std.compat from tangobos std.stdarg .
So the severity is less important.
Comment #3 by larsivar — 2008-04-01T10:02:32Z
I don't think it is less important - even if it solves the particular problem leading up to this report.