Thread overview
GDC can't link LuaD if separate compilation used (bug?)
Apr 27, 2014
ketmar
Apr 27, 2014
Iain Buclaw
Apr 27, 2014
ketmar
April 27, 2014
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
April 27, 2014
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

April 27, 2014
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).