FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

DMD 0.96 and DWT

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Forum Index -> DWT
View previous topic :: View next topic  
Author Message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jul 25, 2004 1:32 pm    Post subject: DMD 0.96 and DWT Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jul 25, 2004 1:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jul 25, 2004 4:19 pm    Post subject: Reply with quote

Smile

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jul 25, 2004 4:25 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jul 25, 2004 4:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jul 25, 2004 4:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jul 25, 2004 6:17 pm    Post subject: Reply with quote

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. Razz

I've been going at it all day, and apparently getting nowhere with it.
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jul 25, 2004 6:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Sun Jul 25, 2004 8:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Mon Jul 26, 2004 2:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Mon Jul 26, 2004 6:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Mon Jul 26, 2004 11:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Tue Jul 27, 2004 12:21 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Jul 27, 2004 3:51 am    Post subject: Reply with quote

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. Sad
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Thu Jul 29, 2004 9:17 am    Post subject: Reply with quote

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. Surprised

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. Sad

I would expect the whole OS class to be replaced with module-level functions at a later date anyway. Smile
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Forum Index -> DWT All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group