[Issue 6461] multiple definitions with typeid and multiobj (page 2)

http://d.puremagic.com/issues/show_bug.cgi?id=6461 --- Comment #9 from Rainer Schuetze <r.sagitario@gmx.de> 2013-05-31 00:06:58 PDT --- (In reply to comment #6) > Generating a UUID instead of the simple static counter in obj_write_deferred seems to fix the problem. Probably the better fix might be to not generate pseudo-ModuleInfo at all. In addition, without a module the TypeInfo symbol is merged into the previous (possibly unrelated) object file. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6461 --- Comment #10 from Martin Nowak <code@dawg.eu> 2013-05-31 05:17:57 PDT --- (In reply to comment #9) > (In reply to comment #6) > > Generating a UUID instead of the simple static counter in obj_write_deferred seems to fix the problem. > > Probably the better fix might be to not generate pseudo-ModuleInfo at all. In addition, without a module the TypeInfo symbol is merged into the previous (possibly unrelated) object file. Yeah UUIDs might work but we should instead remove the ugly hack that causes the multiple definitions, i.e. "mname = lastmname;". IIRC TypeInfo instances were the only symbols where s->getModule() returns NULL. But a TypeInfo instance should belong to the module of the described Type. I hope that we can remove the hack if we fix that behavior and assert s->getModule. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6461 --- Comment #11 from Rainer Schuetze <r.sagitario@gmx.de> 2013-05-31 07:29:21 PDT --- (In reply to comment #10) > IIRC TypeInfo instances were the only symbols where s->getModule() returns > NULL. I had the impression that the init-data has the same problem, but I could also have been confused by other issues (the multiobj library creation doesn't work at all for omf atm). > But a TypeInfo instance should belong to the module of the described Type. I hope that we can remove the hack if we fix that behavior and assert s->getModule. The problem also exists for derived types like const(Struct) or Struct* (maybe also for basic types?). You cannot generate all possible types into the module itself (and you might not have it compiled anyway if the declaration is only in a di file). E.g. for const(Struct) you'll have to at least generate the TypeInfo_Const that refers to TypeInfo_Struct somewhere into the current compiler output. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

May 31, 2013

[Issue 6461] multiple definitions with typeid and multiobj

Posted by Martin Nowak
in reply to dawg@dawgfoto.de

Permalink

Martin Nowak

Posted in reply to dawg@dawgfoto.de

Permalink

http://d.puremagic.com/issues/show_bug.cgi?id=6461



--- Comment #12 from Martin Nowak <code@dawg.eu> 2013-05-31 09:19:19 PDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > IIRC TypeInfo instances were the only symbols where s->getModule() returns
> > NULL.
> 
> I had the impression that the init-data has the same problem, but I could also have been confused by other issues (the multiobj library creation doesn't work at all for omf atm).
> 
> > But a TypeInfo instance should belong to the module of the described Type. I hope that we can remove the hack if we fix that behavior and assert s->getModule.
> 
> The problem also exists for derived types like const(Struct) or Struct* (maybe
> also for basic types?). You cannot generate all possible types into the module
> itself (and you might not have it compiled anyway if the declaration is only in
> a di file). E.g. for const(Struct) you'll have to at least generate the
> TypeInfo_Const that refers to TypeInfo_Struct somewhere into the current
> compiler output.

True, but wouldn't it still make sense to emit these into a doppelgänger module of the original module? One problem is, that this required linking against the original module, because it references assert etc.

As this only seems to happen with data we don't actually need the module
functions, so we could omit them.
Also emitting them to a doppelgänger of a special anonymous module would make
more sense than to reuse the last filename.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6461 Denis Shelomovskij <verylonglogin.reg@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P1 Severity|major |critical --- Comment #13 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-06-04 22:15:14 MSD --- Partial workaround: One can try to detrigger the issue by minimizing module count i.e. for `mylib.*` library which forces you projects to fail building create `mylib_all` module with copied contents of all library files and replace `import mylib.` with `import mylib_all; //mylib.` for easy replacing back once the issue is fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6461 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@digitalmars.com Platform|Other |All Version|D2 |D1 & D2 --- Comment #14 from Walter Bright <bugzilla@digitalmars.com> 2013-06-09 02:41:42 PDT --- https://github.com/D-Programming-Language/dmd/pull/2151 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6461 --- Comment #15 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-06-10 10:23:08 MSD --- Created an attachment (id=1221) Testcase -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6461 --- Comment #16 from Walter Bright <bugzilla@digitalmars.com> 2013-06-26 22:48:22 PDT --- https://github.com/D-Programming-Language/dmd/pull/2201 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums