View previous topic :: View next topic |
Author |
Message |
ShadowIce
Joined: 27 Dec 2006 Posts: 6
|
Posted: Wed Dec 27, 2006 8:09 pm Post subject: undefined reference with dmd 0.178 |
|
|
I'm getting the following undefined reference errors with dmd 0.178 and can't figure out how to fix that. The same program worked with dmd 0.167 and I don't think I've changed anything besides building Derelict with the new version of dmd.
-------------- Build: Debug in test ---------------
dmd -g -D -I/usr/lib/phobos -I/usr/lib -c hello.d -ofobj/Debug/hello.o
gcc -o bin/Debug/test obj/Debug/hello.o -lDerelictGL -lDerelictSDL -lDerelictUtil -ldl -lpthread -lm -lphobos
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../libDerelictGL.a(glx.o):(.gnu.linkonce.d._D47TypeInfo_ S8derelict6opengl3glx15__GLXcontextRec6__initZ+0x14): undefined reference to `_D8derelict6opengl3glx15__GLXcontextRec6__initZ'
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../libDerelictGL.a(glx.o):(.gnu.linkonce.d._D48TypeInfo_ S8derelict6opengl3glx16__GLXFBConfigRec6__initZ+0x14): undefined reference to `_D8derelict6opengl3glx16__GLXFBConfigRec6__initZ'
collect2: ld gab 1 als Ende-Status zurück
Process terminated with status 1 (0 minutes, 7 seconds)
0 errors, 0 warnings
Any ideas? :? |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Thu Dec 28, 2006 12:09 am Post subject: |
|
|
First, are you using the latest trunk?
Second, does the problem happen when you compile Derelict directly into the program (with bud, for example) rather than linking with the libraries?
I'm not a Linux user and currently don't have a Linux box to test on, so I can't help you much. I do, however, recommend that you use bud when compiling rather than using the dmd command line and linking to the libraries directly. The buildme script is provided for those who really, really, want it, but using bud is the recommended approach. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Thu Dec 28, 2006 1:13 am Post subject: |
|
|
This is a problem that started with DMD 0.177 and was reported here in the forum and on my blog by Clayasaurus, and also in the NG by a couple of other people. Here's part of Clay's forum post:
Quote: |
Aldacron,
I noticed something else in derelict. For some reason code that looks like...
struct MyStruct;
needs to be replaced with
struct MyStruct {}
or else DMD will not recognize the symbols on either windows or linux with the latest (dmd .177) compiler.
|
He says the problem happens on both Windows and Linux, but I was unable to reproduce it on Windows at all, using both 0.177 and 0.178.
I just committed the the changes. Every occurrence I could find of the forward declaration style was replaced with a regular struct declaration. I don't like it because it allows people to do stupid things, like this:
MyStruct ms;
Since I couldn't reproduce the problem on Windows, I couldn't try any alternative declarations. If you, or any other Linux user, could try this form of forward declaration:
extern(C) MyStruct ms;
and tell me if it works, I'd appreciate it. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
Crispy
Joined: 26 Nov 2005 Posts: 67
|
Posted: Thu Dec 28, 2006 2:53 am Post subject: |
|
|
I had this problem on Windows (and fixed it locally).
None of these work (using derelict.sdl.ttf to test):
struct _TTF_Font;
extern(C) struct _TTF_Font;
extern(Windows) struct _TTF_Font;
The problem appears to be that the symbol isn't being put into Derelict's object file, and therefore the linker can't find it. I think you'll probably need to define it (using {}) for it to work - just declaring it won't cut it.
Since the intent in all of these cases is to basically treat the struct as opaque data, perhaps you could just do:
typedef void TTF_Font;
That way TTF_Font* pointers will simply be parsed as void* pointers. I tested this briefly and it appears to work fine (my game still loads and displays text correctly using the TTF library). |
|
Back to top |
|
|
ShadowIce
Joined: 27 Dec 2006 Posts: 6
|
Posted: Thu Dec 28, 2006 3:37 am Post subject: |
|
|
Just downloaded the latest trunk (205). Seems to be fixed now with those
struct ... { }.
Thanks for the fast fix. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Thu Dec 28, 2006 4:42 am Post subject: |
|
|
Crispy wrote: | The problem appears to be that the symbol isn't being put into Derelict's object file, and therefore the linker can't find it. I think you'll probably need to define it (using {}) for it to work - just declaring it won't cut it. |
It's not finding the .init property of the struct because one doesn't exist in a forward declaration. Prior to 0.177, I would guess that the linker wasn't looking for an .init property on foward declared structs. I've looked over the changelog for 0.177 and the only thing I can see that might have changed this behavior is the following:
Quote: | TypeInfo now always generated for enum, struct, and typedef's, to enable more thorough rtti. |
My guess is that the new generated TypeInfo for a struct somehow depends upon the struct's .init property and that the code for that doesn't distinguish between a forward declaration and a regular struct declaration. If that's the case, then this would be inserting a call to an init property that the linker can't find.
Quote: |
Since the intent in all of these cases is to basically treat the struct as opaque data, perhaps you could just do:
typedef void TTF_Font;
That way TTF_Font* pointers will simply be parsed as void* pointers. I tested this briefly and it appears to work fine (my game still loads and displays text correctly using the TTF library). |
Yes, maybe a better solution. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
|