| View previous topic :: View next topic |
| Author |
Message |
clayasaurus
Joined: 21 May 2004
Posts: 857
|
 Posted: Mon Feb 28, 2005 1:35 pm Post subject: |
 |
|
ok, well i can compile it now, but DerelictGL_Load throws an exception.
anyway, here is the message i get
"Failed to load shared library Failed to load shared library libGL.so"
edit: sorry for the confusion, before i was exiting my program and then trying to write the exception, and i hoped you wouldn't read my post by that time
Last edited by clayasaurus on Mon Feb 28, 2005 1:51 pm; edited 1 time in total |
|
| Back to top |
|
 |
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Feb 28, 2005 1:47 pm Post subject: |
|
|
Clay, I don't understand what you mean. You say DirelictGL_Load throws an exception. If so, what is output to screen?
Why do you try to print your own message with "e.msg"? Where does "e.msg" come from? Derelict should print its own message to the screen. I don't understand why you need to print one.
I'm wondering if the problem lies in the fact that derelict can't load a library from your system because the default name is incorrect in the library. This could be a problem with GL or GLU. Your system may not define the library names libGL.so or libGLU.so with the appropriate system links to the versioned names.
Aldacron prepared for this situation by adding versions of Derelict*_Load that allow for explicit loading of the required library, eg.
DerelictGL_Load("libGL.so.1.2.0"); //or whatever the name is
I'll continue to try to reproduce the error and fix it.
Later,
JJR |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Mon Feb 28, 2005 2:03 pm Post subject: |
|
|
gahh!! i feel like an idiot now.
anyway, you are right, I just had to put
DerelictGL_Load("libGL.so.1");
and it seemed to accept that name, and I get a new exception error!
"Failed to load proc glXGetProcAddress from shared library libGL.so.1"
well that is nice it tells me which one i need to comment out
 and it works after i comment it out.
i am set for now. thanks for all the help & wonderful work you two have been doing with derelict. peace out. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Feb 28, 2005 2:17 pm Post subject: |
|
|
| clayasaurus wrote: | DerelictGL_Load("libGL.so.1");
and it seemed to accept that name, and I get a new exception error!
"Failed to load proc glXGetProcAddress from shared library libGL.so.1"
well that is nice it tells me which one i need to comment out
and it works after i comment it out.
|
Great! Actually, I think I had some troubles with that function earlier. Part of the problem with importing GLX functions is that not all of them may be available on certain platforms. I guess you found one of them. Commenting out the appopriate line will indeed fix the problem, although it would be nice to have an effective method for determining which functions are available and which are not. It's good, at least, to see that all previous functions loaded properly.
| claysaurus wrote: | | i am set for now. thanks for all the help & wonderful work you two have been doing with derelict. peace out. |
This is almost entirely Aldacron's hard work. I thank him for that too. But your welcome for the small bit I've played.
- JJR |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Feb 28, 2005 2:42 pm Post subject: |
|
|
I haven't actually played with SDL on linux yet. Is the current SVN source building and working?
I'll take a look at the std.loader fix you mention. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Mon Feb 28, 2005 3:07 pm Post subject: |
|
|
| The current SDL, SDL_mixer, and SDL_image are building and working fine with the new util.loader code. That along with OpenGL and OpenGLU are the only libs I use. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Feb 28, 2005 10:35 pm Post subject: |
|
|
| Thanks, clay. I've updated/added several other makefiles so that other derelict subprojects build on linux also. I've tried building all subprojects now, and they build correctly. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Tue Mar 01, 2005 1:29 am Post subject: |
|
|
I've been out of the loop for a couple of days, else I would have seen this sooner.
| clayasaurus wrote: | 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
|
|
This is a copy/paste error. The linux version should never have been using HMODULE at all. I had meant to declare a void* variable on linux, which is what dlopen returns. Sorry about that.
As to the glx issues, I think it's now time to implement something else I have been cosidering - exception handlers. In DerelictUtil, I will set up a mechanism that allows the user to specify a callback (either a function pointer or a delegate) that will be called anytime a function fails to load. If you want the loader to keep going, return true. If you want it to throw and exception, return false. The callback will be prototyped to accept the name of the function that failed, and you can use that to avoid exceptions for cases like your glxGetProcAddress failures. It will also be optional, so that if no callback is specified the exception will be thrown by default.
The problem with this approach is that it leaves open the possiblity of calling a function that wasn't loaded, so you'll need to be vigilant about calling functions you let pass when they couldn't be loaded. I hate adding such complexity to simple bindings, but I don't see any way around it. This will also give the flexibility of avoiding version conflicts. For example, you could load SDL 1.2.5 if you test for the functions that were added in 1.2.6 (CPU info stuff, IIRC). As it stands now, SDL 1.2.5 and lower would cause exceptions. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Tue Mar 01, 2005 1:05 pm Post subject: |
|
|
| aldacron wrote: | This is a copy/paste error. The linux version should never have been using HMODULE at all. I had meant to declare a void* variable on linux, which is what dlopen returns. Sorry about that.
|
Ah... I see. My quick fix was to add an "alias void* HMODULE;" for the linux version. I see now that you would have just added void* to all the HMODULE references in the linux version. Works as is with the update I made. Do you want to change it?
| aldacron wrote: | | As to the glx issues, I think it's now time to implement something else I have been cosidering - exception handlers. In DerelictUtil, I will set up a mechanism that allows the user to specify a callback (either a function pointer or a delegate) that will be called anytime a function fails to load. If you want the loader to keep going, return true. If you want it to throw and exception, return false. The callback will be prototyped to accept the name of the function that failed, and you can use that to avoid exceptions for cases like your glxGetProcAddress failures. It will also be optional, so that if no callback is specified the exception will be thrown by default. |
Another good idea! I like this approach and was vaguely hoping that you would think of something.
| aldacron wrote: | | The problem with this approach is that it leaves open the possiblity of calling a function that wasn't loaded, so you'll need to be vigilant about calling functions you let pass when they couldn't be loaded. I hate adding such complexity to simple bindings, but I don't see any way around it. This will also give the flexibility of avoiding version conflicts. For example, you could load SDL 1.2.5 if you test for the functions that were added in 1.2.6 (CPU info stuff, IIRC). As it stands now, SDL 1.2.5 and lower would cause exceptions. |
As much as you might dislike adding more complexity, I think this is one of those things that is needed because of the very nature of the project. It's a good and useful addition. Granted it requires some consideration from the programmer using the library, but I think it's a reasonable requirement in this case. The addition will add a little more finesse to Derelict.
- JJR |
|
| Back to top |
|
|
Edward-46569
Joined: 20 Aug 2005
Posts: 1
|
| Posted: Mon Aug 29, 2005 4:09 pm Post subject: |
|
|
Oh, My God!
_________________
Wise men don't need advice. Fools won't take it. (Benjamin Franklin)
Sincerily yours, Edward Casino |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Aug 29, 2005 9:14 pm Post subject: |
|
|
| Edward-46569 wrote: | | Oh, My God! |
Would you mind explaining that comment and how it pertains to this topic?
If not, it will be deleted as spam.
Thanks!
-JJR |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
