Bug 11114 – Undefined symbols after merging dmd pull #2550

Merging dmd pull #2550 [1] (commit ba48d3e) causes "Symbol Undefined" linker errors for some templates. The project builds fine before the pull. Application is in `levelling` package, other package are libs it is linked with. OPTLINK errors just after merging, symbols are demangled using VisualD: ---------- Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel6__ctorMFNfC6metaui8controls9container16ContainerControlAC6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5PanelXC6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel (@safe metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.__ctor(metaui.controls.container.ContainerControl, metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel[]...)) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel6sourceMNgFNaNbNdNfZNgC9levelling14LevFileManager14LevFileManager (metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.sourceinout(pure nothrow @property @safe inout(levelling.LevFileManager.LevFileManager) function())) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel6__ctorMFNaNfC6metaui8controls9container16ContainerControlZC6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel (pure @safe metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.__ctor(metaui.controls.container.ContainerControl)) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D3std10functional28__T8unaryFunVAyaa4_74727565Z40__T8unaryFunTC4gtkd3gtk8controls6WidgetZ8unaryFunFNaNbNfC4gtkd3gtk8controls6WidgetZb (pure nothrow @safe bool std.functional.unaryFun!("true").unaryFun!(gtkd.gtk.controls.Widget).unaryFun(gtkd.gtk.controls.Widget)) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D5unstd5casts95__T6upCastTC11levellingui6native10GTKContext10GTKContextTC11levellingui6panels7context7ContextZ6upCastFNaNbNdNfNgC11levellingui6panels7context7ContextZNgC11levellingui6native10GTKContext10GTKContext (pure nothrow @property @safe inout(levellingui.native.GTKContext.GTKContext) unstd.casts.upCast!(levellingui.native.GTKContext.GTKContext, levellingui.panels.context.Context).upCast(inout(levellingui.panels.context.Context))) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel6sourceMFNdNfC9levelling14LevFileManager14LevFileManagerZv (@property @safe void metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.source(levelling.LevFileManager.LevFileManager)) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel20setTypedSourceObjectMFNaNfC6ObjectZv (pure @safe void metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.setTypedSourceObject(Object)) --- errorlevel 7 ---------- Also see Issue 10920 which looks similar but isn't a "regression" so I created a new one. [1] https://github.com/D-Programming-Language/dmd/pull/2550

And the funny thing is: all libraries builds fine and works with latest HEAD. The only thing I have to build without the pull is the final executable.

Could you please post the reduced test case? Posting just only error messages cannot help for fixing the regression.

(In reply to comment #2) > Could you please post the reduced test case? Posting just only error messages > cannot help for fixing the regression. I'd post if I could. Sorry, but I doesn't look possible. Too much code and no obvious auto-reduction criteria. Maybe this will give some info: Here is a module: --- import document.interfaces; import metaui.controls.panel; import levelling.LevFileManager; void f(Panel!IFileManager pnl1, Panel!LevFileManager pnl2) { pnl1.addSubPanel(pnl2, fileMgr => cast(LevFileManager) fileMgr); // line A pnl2.source = null; // line B } --- There are other modules where these Panel!T templates are used. If line A is commented - project builds. If not but line B is commented we get 4 error: ---------- Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel6__ctorMFNfC6metaui8controls9container16ContainerControlAC6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5PanelXC6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel (@safe metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.__ctor(metaui.controls.container.ContainerControl, metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel[]...)) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel6sourceMNgFNaNbNdNfZNgC9levelling14LevFileManager14LevFileManager (metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.sourceinout(pure nothrow @property @safe inout(levelling.LevFileManager.LevFileManager) function())) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel6__ctorMFNaNfC6metaui8controls9container16ContainerControlZC6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel (pure @safe metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.__ctor(metaui.controls.container.ContainerControl)) Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel20setTypedSourceObjectMFNaNfC6ObjectZv (pure @safe void metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.setTypedSourceObject(Object)) --- errorlevel 4 ---------- If line B is also uncommented we get one more error: ---------- ... Debug\Levelling.obj(Levelling) Error 42: Symbol Undefined _D6metaui8controls5panel54__T5PanelTC9levelling14LevFileManager14LevFileManagerZ5Panel6sourceMFNdNfC9levelling14LevFileManager14LevFileManagerZv (@property @safe void metaui.controls.panel.Panel!(levelling.LevFileManager.LevFileManager).Panel.source(levelling.LevFileManager.LevFileManager)) Debug\Levelling.obj(Levelling) ... --- errorlevel 5 ---------- I can also provide remote access to my PC if someone needed.

OK. Sorry, I haven't checked issues and latest pulls. This looks like a dup of Issue 11069 and its fixing dmd pull (#2577 [1]) fixes all but one linker errors. The only rest error is: ---------- Error 42: Symbol Undefined _D5unstd5casts95__T6upCastTC11levellingui6native10GTKContext10GTKContextTC11levellingui6panels7context7ContextZ6upCastFNaNbNdNfNgC11levellingui6panels7context7ContextZNgC11levellingui6native10GTKContext10GTKContext (pure nothrow @property @safe inout(levellingui.native.GTKContext.GTKContext) unstd.casts.upCast!(levellingui.native.GTKContext.GTKContext, levellingui.panels.context.Context).upCast(inout(levellingui.panels.context.Context))) ---------- So I'd say Issue 11069 isn't fully fixed. [1] https://github.com/D-Programming-Language/dmd/pull/2577

(In reply to comment #4) > So I'd say Issue 11069 isn't fully fixed. OK, I checked compiler code on desk, and found two suspicious code places. Could you test this patch on git head (da3d2e6)? src/template.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/template.c b/src/template.c index b7c58ca..a4f67f3 100644 --- a/src/template.c +++ b/src/template.c @@ -1122,10 +1122,8 @@ MATCH TemplateDeclaration::deduceFunctionTemplateMatch(FuncDeclaration *f, Loc l paramsym->parent = scope->parent; Scope *paramscope = scope->push(paramsym); - paramscope->instantiatingModule = sc->instantiatingModule; Module *mi = sc->instantiatingModule ? sc->instantiatingModule : sc->module; - if (!sc->instantiatingModule || sc->instantiatingModule->isRoot()) - paramscope->instantiatingModule = mi; + paramscope->instantiatingModule = mi; paramscope->callsc = sc; paramscope->stc = 0; @@ -2640,7 +2638,8 @@ FuncDeclaration *TemplateDeclaration::doHeaderInstantiation(Scope *sc, ti->argsym = new ScopeDsymbol(); ti->argsym->parent = scope->parent; scope = scope->push(ti->argsym); - scope->instantiatingModule = sc->instantiatingModule; + Module *mi = sc->instantiatingModule ? sc->instantiatingModule : sc->module; + scope->instantiatingModule = mi; bool hasttp = false;

(In reply to comment #5) > (In reply to comment #4) > > So I'd say Issue 11069 isn't fully fixed. > > OK, I checked compiler code on desk, and found two suspicious code places. > > Could you test this patch on git head (da3d2e6)? Thanks, but same failure occurs with the patch.

Issue 11127 is also a regression caused by pull #2550. For that, I opened: https://github.com/D-Programming-Language/dmd/pull/2590 Denis, may the pull #2590 fix your link-failure?

(In reply to comment #7) > Issue 11127 is also a regression caused by pull #2550. For that, I opened: > https://github.com/D-Programming-Language/dmd/pull/2590 > > Denis, may the pull #2590 fix your link-failure? Thanks but negative again.

Denis, we're going to need some more help with this, i.e. code we can compile that duplicates the error.

(In reply to comment #9) > Denis, we're going to need some more help with this, i.e. code we can compile > that duplicates the error. The project is not open source so I can't post it here. But as I trust dmd developers you can e-mail me (shown here address but better without ".reg" suffix) and I will prepare and send the testcase privately.

This may fix it: https://github.com/D-Programming-Language/dmd/pull/2661 Need to also check if imports are compiled with one -version while the importer is compiled with another -version.

(In reply to comment #11) > This may fix it: > > https://github.com/D-Programming-Language/dmd/pull/2661 Why "may"? It will definitely workaround at in debug mode as it disables symbol discarding at all and will have no effect in no-debug mode. This issue isn't related to "-debug" switch. > Need to also check if imports are compiled with one -version while the importer > is compiled with another -version. Not possible. The whole final project is compiled in single dmd call. Just one of the templates it instantiate is assumed by the compiler to belong to one of imported libraries and thus discarded in `FuncDeclaration::toObjFile`.

(In reply to comment #12) > (In reply to comment #11) > > This may fix it: > > > > https://github.com/D-Programming-Language/dmd/pull/2661 > > Why "may"? Because I haven't checked your case, so I don't know if it is the same issue or not. > > Need to also check if imports are compiled with one -version while the importer > > is compiled with another -version. > > Not possible. The whole final project is compiled in single dmd call. Just one > of the templates it instantiate is assumed by the compiler to belong to one of > imported libraries and thus discarded in `FuncDeclaration::toObjFile`. I'm asking if the reason, in your code, it isn't in the imported libraries is because it is behind a version declaration?

(In reply to comment #13) > I'm asking if the reason, in your code, it isn't in the imported libraries is > because it is behind a version declaration? Impossible. The symbol belongs to the final executable-compiled project (it is a template from the library instantiated with project's own types) which is compiled in a single dmd call as I already have written.

(In reply to comment #14) > (In reply to comment #13) > > I'm asking if the reason, in your code, it isn't in the imported libraries is > > because it is behind a version declaration? > > Impossible. The symbol belongs to the final executable-compiled project (it is > a template from the library instantiated with project's own types) which is > compiled in a single dmd call as I already have written. If it is compiled in one a single dmd call, then it wouldn't be linking in other libraries?

(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > I'm asking if the reason, in your code, it isn't in the imported libraries is > > > because it is behind a version declaration? > > > > Impossible. The symbol belongs to the final executable-compiled project (it is > > a template from the library instantiated with project's own types) which is > > compiled in a single dmd call as I already have written. > > If it is compiled in one a single dmd call, then it wouldn't be linking in > other libraries? It links in other libraries. But other libraries can't contain symbols consisting of types they don't know about.

Can you please try this with the new -allinst switch?

(In reply to comment #17) > Can you please try this with the new -allinst switch? I have already written few times where exactly is the problem. So `-allinst` on final executable build workarounds the issue just like all other such issues with incorrect `instantiatingModule`.

(In reply to comment #10) > (In reply to comment #9) > > Denis, we're going to need some more help with this, i.e. code we can compile > > that duplicates the error. > > The project is not open source so I can't post it here. But as I trust dmd > developers you can e-mail me (shown here address but better without ".reg" > suffix) and I will prepare and send the testcase privately. You can use DustMite's --obfuscate option to automatically prepare a test case from proprietary code.

Until available test case will be posted, we cannot confirm the issue. But I know some linker issue exists in current dmd code. So I downgrade the importance to 'nromal'.

Is this issue still valid? We don't have a reduced test case and it's been ~8 years since anybody has looked at it.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18680 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB