Bug 1508 – dmd/linux template symbol issues

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.

$ 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.

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.

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.

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

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

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.

Fixed dmd 1.024 and 2.008