https://issues.dlang.org/show_bug.cgi?id=23850
kinke <ki...@gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ki...@gmx.net
--- Comment #1 from kinke <ki...@gmx.net> ---
Templates highly complicate matters. Little contrived example: an application
with `app.d`, depending on a shared lib with `sharedlib.d`, which further
depends on a `staticlib.d` static library:
app.d:
```
void foo() {
import sharedlib;
sharedFoo!();
}
```
sharedlib.d:
```
void sharedFoo()() {
import staticlib;
staticFoo!();
}
```
staticlib.d:
```
void staticFoo()() {
bar();
}
private void bar() {}
```
The staticlib.lib library contains `bar()` only. If sharedlib doesn't
instantiate `staticFoo!()` itself, sharedlib.dll contains no `staticFoo`
symbol, and the staticlib.obj object file isn't linked into the DLL either
(provides no required symbols). So it's the actual app which contains both
`sharedFoo` and `staticFoo` symbols, but still depends on the non-templated
`bar` function. So the app needs to be linked against staticlib.lib too, a
transitive dependency from the shared lib.
Things become interesting if `staticFoo` is instantiated and codegen'd in
sharedlib.dll. Then a per-module flag doesn't suffice anymore - staticlib.d's
`staticFoo()` part is linked from the shared library, but `bar()` from the
static lib.
--
