Thread overview | |||||
---|---|---|---|---|---|
|
April 27, 2014 GDC can't link LuaD if separate compilation used (bug?) | ||||
---|---|---|---|---|
| ||||
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 Re: GDC can't link LuaD if separate compilation used (bug?) | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | 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 Re: GDC can't link LuaD if separate compilation used (bug?) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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).
|
Copyright © 1999-2021 by the D Language Foundation