www.digitalmars.com         C & C++   DMDScript  

D.gnu - GDC can't link LuaD if separate compilation used (bug?)

reply "ketmar" <ketmar ketmar.no-ip.org> writes:
if i take LuaD[1] and then try to compile it as a set of separate 
.o files, gdc refuses to link any LuaD sample with message:
hello.o:(.data._D30TypeInfo_S4luad4base9LuaObject6__initZ[_D30TypeInfo_S4luad4base9LuaOb
ect6__initZ]+0x1c): 
undefined reference to 
`_D4luad4base9LuaObject11__xopEqualsFKxS4luad4base9LuaObjectKxS4luad4base9LuaObjectZb'

but if i'll do whole thing at once (i.e. passing all .d files in 
command line w/o separate linking phase), everything working ok.

here is two scripts that should be put in root LuaD directory to 
reproduce the issue:

linking failed: http://pastebin.com/Vh27BFBP
everything ok: http://pastebin.com/Gzn7B1Du

i'm using gdc 3209d01d42b6e… and gcc 4.9 on GNU/Linux, x86. here 
is gcc -v output:

Configured with: ../gcc-4.9.0/configure --prefix=/usr 
--libdir=/usr/lib --mandir=/usr/man --infodir=/usr/info 
--disable-nls --enable-shared --enable-bootstrap 
--enable-languages=c,c++,lto,objc,d --enable-threads=posix 
--enable-checking=release --enable-objc-gc --with-system-zlib 
--without-python --disable-libunwind-exceptions 
--enable-__cxa_atexit --enable-libssp --with-gnu-ld 
--with-arch-directory=i386 --disable-gtktest --with-arch=i486 
--target=i486-slackware-linux --build=i486-slackware-linux 
--host=i486-slackware-linux

1. https://github.com/JakobOvrum/LuaD
Apr 26 2014
next sibling parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 27 April 2014 05:30, ketmar via D.gnu <d.gnu puremagic.com> wrote:
 if i take LuaD[1] and then try to compile it as a set of separate .o files,
 gdc refuses to link any LuaD sample with message:
 hello.o:(.data._D30TypeInfo_S4luad4base9LuaObject6__initZ[_D30TypeInfo_S4luad4base9LuaObject6__initZ]+0x1c):
 undefined reference to
 `_D4luad4base9LuaObject11__xopEqualsFKxS4luad4base9LuaObjectKxS4luad4base9LuaObjectZb'

 but if i'll do whole thing at once (i.e. passing all .d files in command
 line w/o separate linking phase), everything working ok.

 here is two scripts that should be put in root LuaD directory to reproduce
 the issue:

 linking failed: http://pastebin.com/Vh27BFBP
 everything ok: http://pastebin.com/Gzn7B1Du

 i'm using gdc 3209d01d42b6e… and gcc 4.9 on GNU/Linux, x86. here is gcc -v
 output:

 Configured with: ../gcc-4.9.0/configure --prefix=/usr --libdir=/usr/lib
 --mandir=/usr/man --infodir=/usr/info --disable-nls --enable-shared
 --enable-bootstrap --enable-languages=c,c++,lto,objc,d
 --enable-threads=posix --enable-checking=release --enable-objc-gc
 --with-system-zlib --without-python --disable-libunwind-exceptions
 --enable-__cxa_atexit --enable-libssp --with-gnu-ld
 --with-arch-directory=i386 --disable-gtktest --with-arch=i486
 --target=i486-slackware-linux --build=i486-slackware-linux
 --host=i486-slackware-linux

 1. https://github.com/JakobOvrum/LuaD

The opEquals implementation of LuaObject is a template. So it's symbol won't be instantiated when compiling luad.base on it's own. https://github.com/JakobOvrum/LuaD/blob/master/luad/base.d#L184 It's also likely that the compiler's rules for whether or not an instantiated template needs to be emitted, decides to instead discard opEquals when compiling the other modules separately. Try compiling with -femit-templates to force the behaviour of D prior to 2.064, see this bug report: https://issues.dlang.org/show_bug.cgi?id=11114 Regards Iain
Apr 27 2014
prev sibling parent "ketmar" <ketmar ketmar.no-ip.org> writes:
On Sun, 27 Apr 2014 10:27:37 +0100
"Iain Buclaw via D.gnu" <d.gnu puremagic.com> wrote:

 Try compiling with -femit-templates to force the behaviour of D 
 prior
 to 2.064, see this bug report:

base.o from LuaD, not before, everything is linking without any problems. seems that gdc emits templates, but linker just don't know about their existanse before it meets 'em (which is logical, but confusing -- this means that i should add my libraries first and main .o file last; have to fix my build tool for this case). and i don't neet -femit-templates (actually, adding this flag changes nothing at all, only linking order matters).
Apr 27 2014