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

           Summary: dmd/linux template symbol issues
           Product: D
           Version: 1.021
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: link-failure
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: braddr@puremagic.com


I think I've reduced this as much as I can, sorry, it's four files.

main.d
----
module main;
void main() {}
----

a.d
----
module a;

private import c;

interface I
{
    void anything();
}

class A : I
{
    private C!(char) c;
    this() { c = new C!(char) (); }
    void anything() {}
}
----

b.d
----
module b;

private import c;

class B
{
    private C!(char) c;
    this() { c = new C!(char); }
}
----

c.d
----
module c;

class C(T)
{
    void foo() { }
}
----

build instructions:
$ for x in a b c d main; do dmd -c $x; done
$ gcc main.o b.o a.o c.o -o main -m32 -Xlinker
-L/home/braddr/sandbox/d/dmd/1.021/dmd/bin/../lib -lphobos -lpthread -lm

error message: `.gnu.linkonce.t_D1c8__T1CTaZ1C3fooMFZv' referenced in section `.data' of a.o: defined in discarded section `.gnu.linkonce.t_D1c8__T1CTaZ1C3fooMFZv' of a.o

$ echo "_D1c8__T1CTaZ1C3fooMFZv" | ../../demangle/demangle void c.C!(char).C.foo(void*)

$ nm a.o | ../../demangle/demangle
00000060 D Z a.__ModuleInfo
00000000 T class a.A a.A._ctor(void*)
0000005c R Z a.A.__init
00000070 R Z a.A.__vtbl
00000000 D Z a.A.__Class
00000000 T void a.A.anything(void*)
00000004 R Z a.I.__Interface
00000000 T void c.C!(char).C.foo(void*)
00000000 D Z c.C!(char).C.__init
00000000 D Z c.C!(char).C.__vtbl
00000000 D Z c.C!(char).C.__Class
         U Z Object.__Class
         U int object.Object.opCmp(class Object, void*)
         U void object.Object.print(void*)
         U uint object.Object.toHash(void*)
         U int object.Object.opEquals(class Object, void*)
         U char[] object.Object.toString(void*)
         U Z ClassInfo.__vtbl
         U void invariant._d_invariant(class Object)
         U _Dmodule_ref
0000000c t _TMP0
         U _d_newclass
00000000 t gcc2_compiled.

$ nm b.o | ../../demangle/demangle
00000048 D Z b.__ModuleInfo
00000000 T class b.B b.B._ctor(void*)
00000010 R Z b.B.__init
00000020 R Z b.B.__vtbl
00000000 D Z b.B.__Class
00000000 T void c.C!(char).C.foo(void*)
00000000 D Z c.C!(char).C.__init
00000000 D Z c.C!(char).C.__vtbl
00000000 D Z c.C!(char).C.__Class
         U Z Object.__Class
         U int object.Object.opCmp(class Object, void*)
         U void object.Object.print(void*)
         U uint object.Object.toHash(void*)
         U int object.Object.opEquals(class Object, void*)
         U char[] object.Object.toString(void*)
         U Z ClassInfo.__vtbl
         U void invariant._d_invariant(class Object)
         U _Dmodule_ref
         U _d_newclass
00000000 t gcc2_compiled.

$ nm c.o | ../../demangle/demangle
00000000 D Z c.__ModuleInfo
00000000 T Z c.__array
00000000 T void c.__assert(int)
         U _Dmodule_ref
00000008 r _TMP0
         U _d_array_bounds
         U _d_assert
00000000 t gcc2_compiled.


-- 

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





------- Comment #1 from braddr@puremagic.com  2007-09-16 19:03 -------
$ nm a.o | ../../../demangle/demangle
00000000 T class a.A a.A._ctor(void*)
00000014 R Z a.A.__init
00000028 R Z a.A.__vtbl
00000060 D Z a.A.__Class
00000026 T void a.A.anything(void*)
00000000 D Z a.I.__Interface
00000000 W void c.C!(char).C.foo(void*)
00000000 V Z c.C!(char).C.__init
00000000 V Z c.C!(char).C.__vtbl
00000000 V Z c.C!(char).C.__Class
         U Z Object.__Class
         U int object.Object.opCmp(class Object, void*)
         U void object.Object.print(void*)
         U uint object.Object.toHash(void*)
         U int object.Object.opEquals(class Object, void*)
         U char[] object.Object.toString(void*)
         U Z ClassInfo.__vtbl
         U void invariant._d_invariant(class Object)
         U __gdc_personality_v0
00000039 t __t12__D1a1A8anythingMFZv.1000
         U _d_newclass

$ nm b.o | ../../../demangle/demangle
00000000 T class b.B b.B._ctor(void*)
00000010 R Z b.B.__init
00000020 R Z b.B.__vtbl
00000000 D Z b.B.__Class
00000000 W void c.C!(char).C.foo(void*)
00000000 V Z c.C!(char).C.__init
00000000 V Z c.C!(char).C.__vtbl
00000000 V Z c.C!(char).C.__Class
         U Z Object.__Class
         U int object.Object.opCmp(class Object, void*)
         U void object.Object.print(void*)
         U uint object.Object.toHash(void*)
         U int object.Object.opEquals(class Object, void*)
         U char[] object.Object.toString(void*)
         U Z ClassInfo.__vtbl
         U void invariant._d_invariant(class Object)
         U __gdc_personality_v0
         U _d_newclass

$ nm c.o | ../../../demangle/demangle
<no symbols>
===========

A key difference is that gdc makes the template symbols weak and dmd doesn't.

One thing I failed to note in the original description, perturbing the order of the .o's on the gcc line affects the results.  a before b works, b before a doesn't.  When building with gdc, the order doesn't matter.. at least in the orders I've tried.


-- 

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


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




------- Comment #2 from bugzilla@digitalmars.com  2007-10-01 23:27 -------
Cannot reproduce the problem on either Windows or Linux, with DMD 1.021 or 2.005. It may be a problem specific to the linker you have.


-- 

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


braddr@puremagic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |




------- Comment #3 from braddr@puremagic.com  2007-10-02 02:06 -------
Well, I absolutely can reproduce it, quite easily.  The version of gcc involved is 4.2.1 and ld version 2.18.

Regardless of if the linker on your box digests it, from what I can tell, it's not a legal construction and newer linkers are blocking it.  I'm not terribly well versed in link-once vs weak symbols.  Time to do more reading I guess.

I just confirmed that I see this same problem with 2.004 as well as 1.021.


-- 

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


daniel.keep+d.puremagic.com@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.keep+d.puremagic.com@
                   |                            |gmail.com




------- Comment #4 from daniel.keep+d.puremagic.com@gmail.com  2007-10-02 04:15 -------
I can confirm for DMD 1.021 running under Ubuntu 7.04 with latest packages.  It appears that the only thing that matters is the relative order or a.o and b.o to the linker; if b.o comes first, it will not link.  If a.o comes first, it does link.

$ uname -a
Linux shuriken 2.6.20-16-generic #2 SMP Sun Sep 23 19:50:39 UTC 2007 i686
GNU/Linux

$ gcc --version | head 1
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)

$ dmd | head 1
Digital Mars D Compiler v1.021


-- 

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


moritzwarning@web.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |moritzwarning@web.de




------- Comment #5 from moritzwarning@web.de  2007-10-06 19:29 -------
I can confirm the problem, too.
(I used Tango, but that shouldn't matter)
When I link in this order "main.o a.o b.o c.o" - it works.

Debian unstable, (kernel 2.6.18-5-486)

$gcc --version | head 1
gcc (GCC) 4.1.3 20070831 (prerelease) (Debian 4.1.2-16)

$ dmd | head 1
Digital Mars D Compiler v1.022

$for x in a b c main; do dmd -c $x -I/opt/dmd/import ; done
$gcc main.o b.o a.o c.o -o main -m32 -Xlinker -L/opt/dmd/lib -lphobos -lpthread
-lm
`.gnu.linkonce.t_D1c8__T1CTaZ1C3fooMFZv' referenced in section `.data' of a.o:
defined in discarded section `.gnu.linkonce.t_D1c8__T1CTaZ1C3fooMFZv' of a.o


-- 

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


larsivar@igesund.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical




------- Comment #6 from larsivar@igesund.net  2007-11-24 07:15 -------
I'm upping the severity - this issue requires intrusive workarounds that you won't know is needed until linking an application barfs on some template instance (of a template in a library) being discarded. Thus you have to modify the library to fix your application. This is not acceptable, and makes DMD on Linux hard to recommend beyond the most trivial tasks.


-- 

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


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




------- Comment #7 from bugzilla@digitalmars.com  2007-12-04 23:35 -------
Fixed dmd 1.024 and 2.008


--