www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GDC Compile Error

reply %u <wfunction hotmail.com> writes:
I'm not sure if this is the best place to put this question, but since I'm
guessing people here have managed to get GDC to compile D2, I thought I'd ask:

So I just downloaded GDC from
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.5.2-tdm-1-gdc-r546-20110417.zip
 and also TDM's GCC from  http://tdm-gcc.tdragon.net/download  and attempted
to compile a D file with it, and I ran into errors.

When I tried compiling a D file (without -static), I got these errors:
 C:\[...]\ccIiRY15.o:Temp.d:(.data+0xa0): undefined reference to
`_D3std1c6wcharh12__ModuleInfoZ'
 c:/mingw32/bin/../lib/gcc/mingw32/4.5.2/../../../libgphobos2.a(dll_helper.o):
In function
`D4core10dll_helper18dll_process_attachFT4core3sys7windows7windows6HANDLEbZb':
 C:\msys\1.0\home\venix\tdm\gdc-d2\dev\build\gcc-tdm32\mingw32\libphobos/../../../../src/gcc-4.5.2/libphobos/co
e/dll_helper.d:359: undefined reference to `_tls_callbacks_a'
 C:\msys\1.0\home\venix\tdm\gdc-d2\dev\build\gcc-tdm32\mingw32\libphobos/../../../../src/gcc-4.5.2/libphobos/co
e/dll_helper.d:359: undefined reference to `_tlsend'
 C:\msys\1.0\home\venix\tdm\gdc-d2\dev\build\gcc-tdm32\mingw32\libphobos/../../../../src/gcc-4.5.2/libphobos/co
e/dll_helper.d:359: undefined reference to `_tlsstart'

Does anyone have any ideas how to fix it?

The command line I ran was:
gdc -v2 -o "Temp.exe" "Temp.d"


Thank you!
Apr 17 2011
parent reply Daniel Green <venix1 gmail.com> writes:
On 4/17/2011 11:09 PM, %u wrote:

 I'm not sure if this is the best place to put this question, but since I'm
 guessing people here have managed to get GDC to compile D2, I thought I'd ask:


D.gnu is the best place for GDC issues and questions.


 Does anyone have any ideas how to fix it?


This is an issue with the way GDC currently handles TLS for MinGW.  It 
currently uses GCC emulation to handle TLS.



 The command line I ran was:
 gdc -v2 -o "Temp.exe" "Temp.d"


Is it possible for you to post the contents of Temp.d?
Apr 17 2011
parent reply %u <wfunction hotmail.com> writes:
 I'm not sure if this is the best place to put this question, but since I'm




guessing people here have managed to get GDC to compile D2, I thought I'd ask:

 D.gnu is the best place for GDC issues and questions.


Ah okay cool. I'll post the code here since you asked but I'll post things there
next time, thanks. :)


 Does anyone have any ideas how to fix it?


 This is an issue with the way GDC currently handles TLS for MinGW.  It
currently


uses GCC emulation to handle TLS.
Yeah, I've run into TLS problems quite a few times before, so I guess this was
to
be expected.



 The command line I ran was:
 gdc -v2 -o "Temp.exe" "Temp.d"


 Is it possible for you to post the contents of Temp.d?


Sure. It's a file I keep handy on my desktop for writing single-use
programs/scripts. :) (Too bad we can't have "global statements" in D, otherwise
we
could easily script with it...)

// Temp.d --------------------------------------------

private import std.algorithm, std.array, std.base64, std.bigint, std.bind,
std.bitmanip, std.compiler, std.complex, std.concurrency, std.container,
std.conv,
std.cpuid, std.ctype, std.demangle, std.encoding, std.exception, std.file, file
=
std.file, std.format, std.functional, std.getopt, std.intrinsic, std.iterator,
std.math, std.md5, std.metastrings, std.mmfile, std.numeric, std.outbuffer,
std.path, std.process, std.random, std.range, std.regex, std.regexp, std.stdio,
std.cstream, std.stream, std.string, std.system, std.traits, std.typecons,
std.typetuple, std.uni, std.uri, std.utf, std.variant, std.c.fenv, std.c.locale,
std.c.math, cprocess = std.c.process, std.c.stdarg, std.c.stddef, cstdlib =
std.c.stdlib, cstring = std.c.string, ctime = std.c.time, std.c.wcharh,
std.windows.charset;
private import core.atomic, core.bitop, core.cpuid, core.dll_helper,
core.exception, core.memory, core.runtime, cstdio = core.stdc.stdio,
core.stdc.wchar_, core.sys.windows.windows, core.thread, core.vararg;

void main(string[] args) { }
Apr 17 2011
parent reply Daniel Green <venix1 gmail.com> writes:
On 4/17/2011 11:44 PM, %u wrote:

 Sure. It's a file I keep handy on my desktop for writing single-use
 programs/scripts. :) (Too bad we can't have "global statements" in D,
otherwise we
 could easily script with it...)


For the time, I'd suggest removing core.dll_helper from your imports.  I 
believe it's mainly used for Dll's written in D.  It'll need to be 
looked at to see how GDC should deal with it.
Apr 17 2011
parent reply %u <wfunction hotmail.com> writes:
 For the time, I'd suggest removing core.dll_helper from your


imports.  I believe it's mainly used for Dll's written in D.  It'll
need to be looked at to see how GDC should deal with it.

Thanks, yeah that makes the errors go away fortunately, though it
still makes me wonder why that's happening. :)
Apr 18 2011
next sibling parent reply Daniel Green <venix1 gmail.com> writes:
On 4/18/2011 5:25 AM, %u wrote:

 Thanks, yeah that makes the errors go away fortunately, though it
 still makes me wonder why that's happening. :)


The module expects the following TLS symbols:
_tlstart
_tlsend
_tls_callbacks_a

The GCC TLS emulation prefixes all outputted symbols with ___emutls_:
  ___emutls_t._tlsstart
  ___emutls_v._tlsend

And does not yet have _tls_callback_a which is a Windows specific symbol.

I imagine that the __gshared attribute keeps GCC from identifying that 
they should be prefixed with ___emutls.
Apr 18 2011
parent reply %u <wfunction hotmail.com> writes:
 The module expects the following TLS symbols:
 _tlstart
 _tlsend
 _tls_callbacks_a
 The GCC TLS emulation prefixes all outputted symbols with ___emutls_:
   ___emutls_t._tlsstart
   ___emutls_v._tlsend
 And does not yet have _tls_callback_a which is a Windows specific symbol.
 I imagine that the __gshared attribute keeps GCC from identifying that they


should be prefixed with ___emutls.

Oh huh, interesting, thanks for the info. Maybe I'll find a hackish way of
fixing
it. :)
Apr 18 2011
parent reply Daniel Green <venix1 gmail.com> writes:
On 4/18/2011 1:57 PM, %u wrote:

 Oh huh, interesting, thanks for the info. Maybe I'll find a hackish way of
fixing
 it. :)


If you could alias the symbols that would work.  You may have to use GCC 
or GAS to do it.

#pragma weak symbol1 = symbol2
     This pragma declares symbol1 to be a weak alias of symbol2.


I unsure what you could do about _tls_callbacks_a since I have no idea 
what it does.  I know that TLS callbacks are a feature of Windows.  I 
believe it's also a symbol emitted by the DMD compiler since I couldn't 
find it's declaration in druntime.

I'm also not very sure what GCC's TLS emulation does.  So the 
suggestions here may fail to work entirely.
Apr 18 2011
parent %u <wfunction hotmail.com> writes:
 If you could alias the symbols that would work.  You may have to use GCC or GAS


to do it.
#pragma weak symbol1 = symbol2
     This pragma declares symbol1 to be a weak alias of symbol2.

 I unsure what you could do about _tls_callbacks_a since I have no idea what it


does.  I know that TLS callbacks are a feature of Windows.  I believe it's also
a
symbol emitted by the DMD compiler since I couldn't find it's declaration in
druntime.

 I'm also not very sure what GCC's TLS emulation does.  So the suggestions here


may fail to work entirely.

Huh, thanks for the suggestion, I'll try it. :)
Apr 18 2011
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
%u wrote:

 For the time, I'd suggest removing core.dll_helper from your


 imports.  I believe it's mainly used for Dll's written in D.  It'll
 need to be looked at to see how GDC should deal with it.
 
 Thanks, yeah that makes the errors go away fortunately, though it
 still makes me wonder why that's happening. :)


core/dll_helper.d has been recently moved to core/sys/windows/_dll.d, so 
you might just have the old import file core/dll_helper.di lying around 
on your disk without the correspondent file being built into druntime.
Apr 18 2011
next sibling parent %u <wfunction hotmail.com> writes:
 core/dll_helper.d has been recently moved to core/sys/windows/_dll.d, so you


might just have the old import file core/dll_helper.di lying around on your disk
without the correspondent file being built into druntime.

Ooh that makes sense, I didn't know that; thanks!
Apr 18 2011
prev sibling parent Daniel Green <venix1 gmail.com> writes:
On 4/18/2011 1:29 PM, Rainer Schuetze wrote:

 core/dll_helper.d has been recently moved to core/sys/windows/_dll.d, so
 you might just have the old import file core/dll_helper.di lying around
 on your disk without the correspondent file being built into druntime.


GDC tends to follow DMD releases for the frontend and phobos.  So 
core/dll_helper.o is part of the runtime.
Apr 18 2011