| View previous topic :: View next topic |
| Author |
Message |
clayasaurus
Joined: 21 May 2004
Posts: 857
|
 Posted: Fri Feb 25, 2005 10:40 pm Post subject: need a little help with derelict |
 |
|
hey, i just recently updated to the latest version of derelict (was working fine before) so i could use the glColor4f function.
the problem is, DerelictGL_Load() now throws an exception :-/
i tried e.print() but it doesn't output anything.
What changes has derelict had that makes it detect shared libs differently?
thx.
edit: I learned that the "ExeModule initialization failed" exception was thrown
edit: DMD .113 on linux |
|
| Back to top |
|
 |
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sat Feb 26, 2005 12:19 am Post subject: |
|
|
Okay, I don't understand why it's failing. That's just odd. If you really need it to work right now, just remove all references to ExeModule_Init, ExeModule_Uninit, and the local variable exemoduleinited in derelict/opengl/gl.d. You may have to do the same in other modules you are using.
I also don't understand what's happening in ExeModule_Init. I'm checking for a return value of -1 as failure, but ExeModule_Init internally calls a function ExeModule_Init_ that is implemented like this:
| Code: |
private int s_init;
private int ExeModule_Init_()
{
return ++s_init > 1;
}
|
So I'm confused on a few points -
1) why am I checking for -1?
2) why is the method returning ++s_init > 1 and NOT ++s_init >= 1 OR ++s_init > 0?
3) why are you getting that exception on Linux, but JJR hasn't seen it - and I haven't seen it on Windows?
I'm wondering if Macs require some sort of special initialization before loading shared libraries manually, or if, like Windows and Linux, no initialization is needed. If the latter is the case (which I suspect it is) then we can just ignore ExeModule_Init in all Derelict packages, since it will never really do anything.
I'll work something out this weekend and have it checked in before Sunday is over. I may just bypass std.loader altogether and implement the same functionality in the upcoming DerelictUtil package. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sat Feb 26, 2005 7:51 am Post subject: |
|
|
I'll check this out on my system. I'm not sure why it fails now on Linux; even more surprising is that it was working before. Claysaurus, are you just trying to use glColor4f? Some recent changes perhaps are making it fail. Maybe I haven't tried Derelict after such changes were put in place.
In it's current form, std.loader is not supported on Macs... I don't think claysaurus is using a mac, though.
As for std.loader, it probably is a good idea to change over to a replacement for std.loader. In my projects, I've changed over to a design similar to what Kris used in mango.ICU. Works great multiplatform and doesn't require phobos' std.loader! If Derelict worked something like that into it's own utility package, it would be an improvement in integration.
- John R. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sat Feb 26, 2005 8:17 am Post subject: |
|
|
| JJR wrote: |
In it's current form, std.loader is not supported on Macs... I don't think claysaurus is using a mac, though. |
Yeah, I was just speculating on the reason for Matthew including init/uninit functions for std.loader. Linux and Win both require no initialization, and when std.loader finally gets ported to Mac (be it through GDC or whatever), will there need to be an init function there? If there is no need for init fuinctions anywhere, then we people who use std.loader can just forget about calling ExeModule_Init.
But with the util package, it's a moot point anyway  |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sat Feb 26, 2005 8:31 am Post subject: |
|
|
| aldacron wrote: | I also don't understand what's happening in ExeModule_Init. I'm checking for a return value of -1 as failure, but ExeModule_Init internally calls a function ExeModule_Init_ that is implemented like this:
| Code: | private int s_init;
private int ExeModule_Init_()
{
return ++s_init > 1;
}
|
|
That's the windows version. The Linux version is slightly different and looks like this:
| Code: | private int ExeModule_Init_()
{
if(1 == ++s_init)
{
return 0;
}
return 1;
} |
Thus the only way for the return to be -1 is if the ExeModule_Unint() function is called more times than the above function:
| Code: | private void ExeModule_Uninit_()
{
if(0 == --s_init)
{
}
} |
| aldacron wrote: |
So I'm confused on a few points -
1) why am I checking for -1?
|
I think because std.loader says a value < 0 returned means the intialisation failed. But I don't really see where that would happen using std.loader's current init function. It really doesn't do much for initialization in its current form.
| aldacron wrote: |
2) why is the method returning ++s_init > 1 and NOT ++s_init >= 1 OR ++s_init > 0?
|
That's the windows version. I'm not sure why it's different than the Linux one. The Linux one should never return -1 from what I see. It returns exactly 0 or 1. Don't know ow Claysaurus got a failure there. I'm thinking something else is going on (hard to know without seeing the code! [hint.. hint].
| aldacron wrote: |
3) why are you getting that exception on Linux, but JJR hasn't seen it - and I haven't seen it on Windows?
|
I'll compile another project just to see if some recent changes are making trouble, but without seeing claysaurus' code, it's hard to determine what's actually taking place.
- John R. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sat Feb 26, 2005 8:37 am Post subject: |
|
|
| aldacron wrote: | | Yeah, I was just speculating on the reason for Matthew including init/uninit functions for std.loader. Linux and Win both require no initialization, and when std.loader finally gets ported to Mac (be it through GDC or whatever), will there need to be an init function there? If there is no need for init fuinctions anywhere, then we people who use std.loader can just forget about calling ExeModule_Init. |
You're right. Init/uninit doesn't seem to have much use at this point. Perhaps it was for a feature to be implemented later on. I recall that Matthew had plans to clean the package up. I don't know if that's still the case.
| aldacron wrote: | | But with the util package, it's a moot point anyway |
Perfect! |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Sat Feb 26, 2005 9:59 am Post subject: |
|
|
I figured out where the problem lies. If I just commend out loadPlatformGL() from DerelictGL_Load(char[] libName) then everything works fine.
So i guess the question is.. why does loadPlatformGL() under linux throw an exception? I didn't see any "throw exception" statements in it
oh well i figured it out. it is the last line in glx loadPlatformGL
| Code: |
glXGetProcAddress = cast(pfglXGetProcAddress) getProc("glXGetProcAddress");
|
|
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sat Feb 26, 2005 10:18 am Post subject: |
|
|
| clayasaurus wrote: | I figured out where the problem lies. If I just commend out loadPlatformGL() from DerelictGL_Load(char[] libName) then everything works fine.
|
Ah, good! Thanks!
| claysaurus wrote: | | So i guess the question is.. why does loadPlatformGL() under linux throw an exception? I didn't see any "throw exception" statements in it |
Because it calls getProc in internal.d which throws an exception on failure. But, you should have seen it print out "Failed to load shared library proc address" if that's really the problem.
| claysaurus wrote: |
oh well i figured it out. it is the last line in glx loadPlatformGL
| Code: |
glXGetProcAddress = cast(pfglXGetProcAddress) getProc("glXGetProcAddress");
|
|
Strange. It's works on my system with no problems. Perhaps glXGetProcAddress isn't available on yours? That seems to be the disadvantage of enabling some extensions. Perhaps this needs some more customization. Mike, any ideas?
In retrospect, are you sure that's really the problem? How do you know that it's dying there? Does it print out the message I described above? Otherwise, it may still not be clear that that's the problem.
- John R. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Sat Feb 26, 2005 11:37 am Post subject: |
|
|
| JJR wrote: |
In retrospect, are you sure that's really the problem? How do you know that it's dying there? Does it print out the message I described above? Otherwise, it may still not be clear that that's the problem.
|
I know that it is the problem, because when I comment out that line my program runs fine, but if I uncomment that line then it throws an exception.
As for my previous errors, I embedded writefln into the exception errors because e.print didn't seem to print anything. So I was just reading what writefln told me. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sat Feb 26, 2005 2:11 pm Post subject: |
|
|
That's really, really weird that you were getting "ExeModule initialization failed" at that particular point. If the function itself were missing from the library you should have gotten a different exception.
Try the latest svn and see if it craps out with a SharedLibProcLoadException. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Sun Feb 27, 2005 4:35 pm Post subject: |
|
|
I can't seem to compile with the latest version 
I created the util/ directory, put the loader + exception.d files in it, and now when I try to compile I get the following errors
| Code: |
derelict/util/loader.d(76): identifier 'HMODULE' is not defined
derelict/util/loader.d(76): HMODULE is used as a type
derelict/util/loader.d(76): variable derelict.util.loader.SharedLib._handle voids have no value
derelict/util/loader.d(79): identifier 'HMODULE' is not defined
derelict/util/loader.d(79): HMODULE is used as a type
derelict/util/loader.d(79): cannot have parameter of type void
|
I'll play around and see if I can't figure it out. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sun Feb 27, 2005 8:42 pm Post subject: |
|
|
I'll attempt to compile the new version again tonight. Are you using the included makefile? It might not work properly on linux. In the past, I've compiled derelict manually and then built the library manually. Optimally we should get things set up so that the "build" tool works on Derelict.
- JJR |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Sun Feb 27, 2005 11:00 pm Post subject: |
|
|
| JJR wrote: | I'll attempt to compile the new version again tonight. Are you using the included makefile? It might not work properly on linux. In the past, I've compiled derelict manually and then built the library manually. Optimally we should get things set up so that the "build" tool works on Derelict.
- JJR |
Hrm.. when I go into the DerelictGL directory and type 'make' i just get this message
| Code: |
make: md: Command not found
make: *** [all] Error 127
|
*confused*
anyway, i'm not quite sure why it matters whether or not I use a makefile vs. any other way of compilation. It's worked with it well in the past. doing a dmd -c derelict/util/loader.d from the same directory gives me the same errors.
Thank you for looking into it though, when I try to fix em' I just get more. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Feb 28, 2005 2:32 am Post subject: |
|
|
| clayasaurus wrote: | Hrm.. when I go into the DerelictGL directory and type 'make' i just get this message
| Code: |
make: md: Command not found
make: *** [all] Error 127
|
*confused*
|
The makefile in the DerelictGL directory is Windows only. I've converted it to a Linux makefile. I'll try to include it in an update shortly. Basically, LR/CR 's have to be removed from the file, backslashes changed to forward slashes, and several system utilities renamed for linux binaries.
| claysaurus wrote: | | anyway, i'm not quite sure why it matters whether or not I use a makefile vs. any other way of compilation. It's worked with it well in the past. doing a dmd -c derelict/util/loader.d from the same directory gives me the same errors. |
It doesn't really matter how you compile it. But I was wondering if you were trying to use a makefile that wasn't working for Linux yet. You weren't, so I see one possibility for the error is removed.
The problem is with the new loader.d tool. It's a simple fix. It looks like Aldacron left out the definiton for HMODULE. Adding:
| Code: | | alias void* HMODULE; |
to the loader.d module should fix it. I've already tried the change with a new linux makefile. Both compile and build the appropriate libderelictgl.a library. I'll update it for now. Aldacron can change/improve as he sees fit when he gets the chance.
| claysaurus wrote: | | Thank you for looking into it though, when I try to fix em' I just get more. |
No problem. Glad to be able to help! |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Feb 28, 2005 2:50 am Post subject: |
|
|
OK. The linux version has been updated. This includes two Linux makefiles converted so that they work properly. I also had to fix the loader.d code for Linux. A couple small identifier errors prevented it from compiling. I was successful in building a util library and the GL library using the makefiles. Clay, please give it a try and tell me if it's working now.
Thanks,
- JJR |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
