• ketmar (24/24) Apr 26 2014 if i take LuaD[1] and then try to compile it as a set of separate
• Iain Buclaw via D.gnu (12/35) Apr 27 2014 The opEquals implementation of LuaObject is a template. So it's
• ketmar (15/18) Apr 27 2014 ah, just discovered the strange thing: if i pass hello.o after

"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

"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

"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:

ah, just discovered the strange thing: if i pass hello.o after 
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).