View previous topic :: View next topic |
Author |
Message |
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Jul 25, 2004 1:32 pm Post subject: DMD 0.96 and DWT |
|
|
As several of us have noted, the most recent version of dmd still chokes on dwt.
Note: I'm using the makefile for the project compile.
From the verbose error messages, I've determined that the file dwt/graphics/gc.d appears to be the culprit. The compiler appears to crash during the code generation phase.
If any of you figure anything else out, please post here for discussion.
- John R. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Jul 25, 2004 1:39 pm Post subject: |
|
|
I guess this isn't the issue because when you compile gc.d as a single file, it compiles fine (Scons method).
I see that scons can compile the files. It just can't seem to link yet. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Jul 25, 2004 4:19 pm Post subject: |
|
|
I've succeeded in linking DWT into dwt.lib. I had to create a new makefile and change a filename to get this far.
I did find certain dmd flags will crash the compiler (don't use -release yet; that flag alone will crash the compiler at gc.d).
Now I'll linke HelloDWT in with the lib and see what happens.... |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Jul 25, 2004 4:25 pm Post subject: |
|
|
Ah well, still in the same place. Linking in dwt.lib with HellowDWT just creates all those undefined symbols again. Doesn't make any sense.
Oh well... I'll keep plugging at it. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Jul 25, 2004 4:39 pm Post subject: |
|
|
Well the undefined symbols are actually a good sign.
You guys probably knew this already, but those symbols represent unimplemented functions.
For example, the first undefined symbol I see is GetKeyboardState which we haven't put in internal/os.d yet.
So the process for getting rid of these symobls mostly just involves filling in the OS calls (looks like there's a lot of them too!).
Thanks to Yuri for all that hard work!
Later,
John
PS. If anyone wants the new makefile, I created, let me know. I put a fair bit of time into it to make sure everything works. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Jul 25, 2004 4:56 pm Post subject: |
|
|
Argh... not quite what I was expecting. Apparently the windows functions ARE declared in OS.d under "static extern (Windows) {}"
I'm curious to know why the linker can't find the actual windows functions. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Jul 25, 2004 6:17 pm Post subject: |
|
|
This is annoying.
OS.d declares the "static extern (windows)" within the class OS. I think this is the source of our problems. I don't think it's allowing the linker to see the external linkage for some strange reasons.
Any ideas on how to fix this? I tired taking the whole extern (windows) section out of the class and placing it above it so it was in the module scope, but this only caused a avalanche of other problems.
We need to figure out a solution to this one.
I've been going at it all day, and apparently getting nowhere with it. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Jul 25, 2004 6:43 pm Post subject: |
|
|
Ok, first problem... and this should have been fixed long ago since it was discussed in this forum already:
"bool" is used in all the extern(Windows) types. This was already identified as incorrect, since bool is aliased to D's bit. We need to use "BOOL" which is defined as an "int" on in the c windows header. The extern probably wouldn't work with their current setup.
This unfortunately does not fix the current problem by itself. |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Sun Jul 25, 2004 8:46 pm Post subject: |
|
|
The problem is a bug in DMD that causes it to mangle the function names even though they are declared as using non-D linkage. (at least, I assume it's a bug in DMD...)
For now, the solution is to pull all the win32 methods out of the OS class and put them in their own module. (presumably, you'd want to write stubs in the OS class which relay to the correct win32 function) _________________ "Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Mon Jul 26, 2004 2:49 pm Post subject: |
|
|
Looks like it's not a bug after all.
news://news.digitalmars.com:119/ce3ier$1c17$1@digitaldaemon.com
Quote: |
The name mangling must be done when within a scope, or the names will
conflict from one class to the next. Having Windows calling convention
supported for member functions is necessary for supporting COM.
I suggest instead using an alias:
private import std.c.windows.windows;
class Win32 {
alias std.c.windows.windows.GetProcAddress GetProcAddress;
} |
_________________ "Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Jul 26, 2004 6:06 pm Post subject: |
|
|
I was wondering if the name lookup stuff would bite us here.
Thanks for the suggestion, Andy. That will probably solve the problem. I'll see if I can make the necessary changes. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Jul 26, 2004 11:12 pm Post subject: |
|
|
andy wrote: | Looks like it's not a bug after all.
news://news.digitalmars.com:119/ce3ier$1c17$1@digitaldaemon.com
Quote: |
The name mangling must be done when within a scope, or the names will
conflict from one class to the next. Having Windows calling convention
supported for member functions is necessary for supporting COM.
I suggest instead using an alias:
private import std.c.windows.windows;
class Win32 {
alias std.c.windows.windows.GetProcAddress GetProcAddress;
} |
|
I can't find the reference to the newsgroup posting above (the link doesn't work for me). What was the thread title?
I'm not sure what to make of this name resolution thing. Walter says it's the way it supposed to be and that it's the way C++ works and all that, but I've yet to find how it makes working in D smooth and painless! In whatever form this issue has appeared, it's proved greatly annoying! And he claims doing this way is supposed to prevent problems?? bwa ha ha ha ha!!!!
Apparently I need to reprogram my mind to think like he does... and then I won't notice the pain of hair pulling... |
|
Back to top |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Tue Jul 27, 2004 12:21 am Post subject: |
|
|
JJR wrote: | I can't find the reference to the newsgroup posting above (the link doesn't work for me). | The web interface reference is digitalmars.D.bugs:1131. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Tue Jul 27, 2004 3:51 am Post subject: |
|
|
Justin: Thanks for pointing it out. I didn't realize that it was a recent post.
Andy:
Do you have any idea why the MoveMemory calls in OS.d work (specifically the extern (Windows) ones). How can windows function calls be overloaded like that and map properly to the windows library?
Everyone:
I've pulled the extern(Windows) functions out of the OS.d module and put them in a separate module in the same directory. I then import them into OS.d. I'll probably have to look at the alias thing if a internal class import doesn't work (ATM it appears to work quite well). Even though we're not supposed to do this anymore because of the name lookup debacle, I can't help but see it's usefulness in this particular situation: it saves rediculous amounts of time adding all those aliases. Inner imports should be explicitly prohibited if they shouldn't be done. |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Thu Jul 29, 2004 9:17 am Post subject: |
|
|
JJR wrote: | Justin: Thanks for pointing it out. I didn't realize that it was a recent post.
Andy:
Do you have any idea why the MoveMemory calls in OS.d work (specifically the extern (Windows) ones). How can windows function calls be overloaded like that and map properly to the windows library? |
nope. I'm kind of surprised that it does.
Quote: | Everyone:
I've pulled the extern(Windows) functions out of the OS.d module and put them in a separate module in the same directory. I then import them into OS.d. I'll probably have to look at the alias thing if a internal class import doesn't work (ATM it appears to work quite well). Even though we're not supposed to do this anymore because of the name lookup debacle, I can't help but see it's usefulness in this particular situation: it saves rediculous amounts of time adding all those aliases. Inner imports should be explicitly prohibited if they shouldn't be done. |
I would expect the whole OS class to be replaced with module-level functions at a later date anyway. _________________ "Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear |
|
Back to top |
|
|
|