| View previous topic :: View next topic |
| Author |
Message |
JJR
Joined: 22 Feb 2004
Posts: 1104
|
 Posted: Thu Feb 17, 2005 5:28 am Post subject: DerelictGLFW on Linux |
 |
|
(Moved this to a new topic for Linux specific troubleshooting)
Current status:
1) Succeeded in compiling "mthello.d" GLFW example. Runs successfully.
2) "Triangle.d" example still fails. It compiles successfully with the correct options provided, but segfaults on run. I'm having a horrible time trying to track down the bug, but I do know the segfault occurs inside the glfwOpenWindow call. glfwInit() runs fine before that. I don't believe there is a problem in the shared library anymore: all c example programs compile and run with the shared library. This appears to be an issue with the D interface to it.
I'll continue to try to track down where glfwOpenWindow() is faulting. 
That said, I would like to point out that the benefits of having a Derelict.glfw are almost completely non-existant on the Linux platform.
As is, these command line flags have to be set in order for the compile to complete successfully (note this is the quick/dirty compile method; improvements can still be made):
| Code: | dmd triangle.d /opt/dmd/lib/glfw.o /opt/dmd/lib/libderelict.a /opt/dmd/lib/glu.o /opt/dmd/lib/loader.o -L-lGLU -L-lGL -L-lX11 -L-lXxf86vm -L-lXext
|
where:
- glfw.o is the compiled derelict.glfw.glfw.d dynamic interface.
- libderelict.a is the archived combination of the dynamic interfaces to gl.o, glfuncs.o, gltypes.o, glx.o, and internal.o.
- glu.o is the compiled derelict.opengl.glu.d dynamic interface.
- The rest of the command line sends associated switches to the linker. All those libraries are necessary or else libglfw.so cannot be loaded by DerelictGLFW_load(). This may be the source of the problem, since those are all dependencies of libglfw.so which is never actually linked into the program until runtime. The C version actually links to the libglfw.so directly as if it were a static library. That's probably enough to make things work correctly (the C version also pulls in all those libraries). Since the D version uses Derelict.glfw to dynamically load, this may cause some unusual problems.
In order to fix this problem, I think a large modification is necessary to the actual C GLFW project. This would involve correctly dynamically loading the appropriate parts of the X11 libraries such that no linking in is necessary. I'm not sure if this is all worth it. As it is a direct link with a small libglfw.so or libglfw.a is all that's needed to get the program running. Thus the benefits are minimal for dynamic loading on the Linux system.
The reason loading the Windows dll is so useful is because the windows platform has such a "lengthy" process for linking to dynamic libraries: that is, you typically need a definintion file (.def) and an import library to complete the process. There's also the pain of different dll formats. Thus, it's make complete sense to create a dynamic loading system like Derelict for the win32 platform. Also there are no extra libraries that you need to link in to make it all work (I'm still not certain why Linux needs those libs in order to get the thing working).
This is kind of a pain to find out after all this work. Oh well... I guess I can say I learned something new.
- John R. |
|
| Back to top |
|
 |
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Feb 17, 2005 6:17 am Post subject: |
|
|
Bleah... figured out the trouble. Now I can start brainstorming the solution. What a relief.
Basically it goes like this:
Problem 1:
As I expressed before, libglfw.so has all the library dependencies I listed before (-L-l commandline options). So the program refuses to load the library with DerelictGLFW_Load() unless all the X symbols are linked in!
Problem 2:
In order to use the opengl features, I'm making use of the nifty derelict.opengl loader. It creates a whole bunch of symbols that exactly match the symbols linked in with the -L-l switches (-L-lgl -L-lglu). Even worse, the linux Derelict imports in the new glx symbols from Derelict.opengl.glx (also defined simultaneously in the libGL.so library). The glx functions are the first functions called within the glfwOpenWindow function because they are necessary for getting the opengl screen ready on X. So those are the first calls to bomb the program.
Fixing the conflict in #2 solves the problem of #1:
I dropped the Derelict.opengl.gl and glu loaders out of the triangle program completely. I imported some separate D "static" modules from elsewhere to define all the gl functions and used only the new Derelict.glfw loader in the program like so:
| Code: | import gl;
import glu;
// import derelict.opengl.gl;
// import derelict.opengl.glu;
import derelict.glfw.glfw;
...
|
The idea is that there should now be no conflict between opengl symbols in the derelict loaders and those in the required link libraries. The link libraries remained in to satisfy glfw's needs during the DerelictGLFW_Load() attempts. They also now satisfy the opengl connection.
Thus, the triangle program ran successfully without issue after a compile and link like this:
| Code: | | dmd triangle.d /opt/dmd/lib/glfw.o /opt/dmd/lib/loader.d -L-lGLU -L-lGL -L-lX11 -L-lXxf86vm -L-lXext |
Now all that's necessary is to figure out a way to eliminate Derelict GLFW's apparent need for all those command line link switches. Derelict's opengl functions can not be used until a solution to this is found.
Phew... somewhat a relief to at least trace the problem to its source.
Why the heck am I still awake?
- John R. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Feb 17, 2005 7:23 am Post subject: |
|
|
Ha... I couldn't let it go... and it paid off. Complete success has been secured!! The sad part of it was that it was such a silly mistake, I don't know what to think of myself. ATM, I'm just happy I found it.
My mistake was simply due to my lack of experience in building shared libraries on Linux. All I had to do was add the link libraries to the commandline that built the shared library GLFW in the first place! Thus there was never a need to fiddle with all those problems with the main program or include -L-l on the commandline: I had created the need by denying them to the shared library in the first place.
So now:
| Code: |
dmd triangle.d /opt/dmd/lib/glfw.o /opt/dmd/lib/libderelict.a /opt/dmd/lib/glu.o /opt/dmd/lib/loader.o -L-ldl |
works perfectly and the program runs great with a fancy spinning triangle. The command can likely be simplified more. glfw.o, glu.o, and loader.o could easily be added to the libderelict.a library to turn it into a single archive:
| Code: | | dmd triangle.d /opt/dmd/lib/libderelict.a -L-ldl |
The "-L-ldl" is currently necessary because of std.loader's inclusion in the project. The project could be modifies someday to remove this dependency by integrating loader code directly into Derelict.
But for now, I'm very happy that I can say GLFW now works on linux. I'll have to include instructions for making the GLFW in it's shared format. I'll likely submit the updated makefile to the GLFW project also.
What a crazy night. And all because of ignorance!
- John R. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Thu Feb 17, 2005 7:55 am Post subject: |
|
|
| JJR wrote: | Ha... I couldn't let it go... and it paid off. Complete success has been secured!! The sad part of it was that it was such a silly mistake, I don't know what to think of myself. ATM, I'm just happy I found it.
My mistake was simply due to my lack of experience in building shared libraries on Linux. All I had to do was add the link libraries to the commandline that built the shared library GLFW in the first place! Thus there was never a need to fiddle with all those problems with the main program or include -L-l on the commandline: I had created the need by denying them to the shared library in the first place.
|
It's kind of like golf isn't it? Sometimes you get so frustrated that you toss your club down the fairway, but you still come back and play again. I've had many late, late nights that I can attribute to little errors like the one you describe. All part of the fun, eh? Glad you sorted it out 
| Quote: |
| Code: |
dmd triangle.d /opt/dmd/lib/glfw.o /opt/dmd/lib/libderelict.a /opt/dmd/lib/glu.o /opt/dmd/lib/loader.o -L-ldl |
works perfectly and the program runs great with a fancy spinning triangle. The command can likely be simplified more. glfw.o, glu.o, and loader.o could easily be added to the libderelict.a library to turn it into a single archive:
| Code: | | dmd triangle.d /opt/dmd/lib/libderelict.a -L-ldl |
The "-L-ldl" is currently necessary because of std.loader's inclusion in the project. The project could be modifies someday to remove this dependency by integrating loader code directly into Derelict.
|
As you are aware, the current Derelict setup builds a new library for each package (even if only one object file is produced for that package). I very much want to create a configurable build system that can build a single Derelict library containing the packages needed for a particular project. Doing this would also make the idea of a Derelict utility package (for common code) more feasible, as it could be bundled up into the single library as well. As it stands, I don't want to include a shared code package because that would mean adding one more dependency to a project (i.e. you must link to libDerelictUtil in order to use libDerelictGL).
And even if there is a shared code package eventually, I don't see how we can avoid the libdl dependency. I mean, we would basically be doing the same thing as std.loader wouldn't we? We can't dynamically load libdl without linking to libdl! Is there another way of manually loading shared libs on Linux? |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Feb 17, 2005 8:27 am Post subject: |
|
|
| aldacron wrote: | | It's kind of like golf isn't it? Sometimes you get so frustrated that you toss your club down the fairway, but you still come back and play again. I've had many late, late nights that I can attribute to little errors like the one you describe. All part of the fun, eh? Glad you sorted it out |
Yep, but the success was more fun than the hair-pulling, I can tell ya that! It's now 0630 hrs here... I was working on it since the pevious evening.
| aldacron wrote: | As you are aware, the current Derelict setup builds a new library for each package (even if only one object file is produced for that package). I very much want to create a configurable build system that can build a single Derelict library containing the packages needed for a particular project. Doing this would also make the idea of a Derelict utility package (for common code) more feasible, as it could be bundled up into the single library as well. As it stands, I don't want to include a shared code package because that would mean adding one more dependency to a project (i.e. you must link to libDerelictUtil in order to use libDerelictGL).
|
Yes, I was aware of the makefiles. I just didn't want to use them since the individual builds were so small. I actually prefer merging all the required objects into one library. The longer the command line the less useful it seems it is to have Derelict (since each could be replaced by the appropriate static lib making the commandline equivilantly complex and equivalently long). I'm not sure what you mean by a util lib, but certainly allowing a customization feature would be an advantage. For different projects, different combinations of Derelict libs could be put together. For now things are fine, though. I don't mind mixing what I need manually, since it's still very simple to do. It's good to think about this for future improvements, though.
| aldacron wrote: | | And even if there is a shared code package eventually, I don't see how we can avoid the libdl dependency. I mean, we would basically be doing the same thing as std.loader wouldn't we? We can't dynamically load libdl without linking to libdl! Is there another way of manually loading shared libs on Linux? |
And you are absolutely right; my suggestion was bizarre and devoid of thought.... Must be lack of sleep; my suggestions are usually just bizarre.
There is no way to avoid including "-L-ldl" on the program commandline.
Catch ya later,
John R. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Feb 17, 2005 9:55 pm Post subject: |
|
|
Completed porting the bigger, more complicated opengl/glfw example "particles." Runs fullscreen perfectly with numerous OpenGL calls and some special extensions. Runs same speed as the C original.
I would say Linux Derelict's OpenGL is now up and running smoothly.
- John R. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Feb 18, 2005 4:01 am Post subject: |
|
|
Completed... "boing" GLFW example on Linux for Derelict. Had some nasty bug that I couldn't figure out...more hair pulling. Surprisingly, the problem was unrelated to the Derelict modules; it ended up being somehow related to D's operator precedence and casting; very strange. It didn't work exactly like it would in C.
To be honest, I had to dig up a currently complete D version of the example available in the GLFW project's CVS (a windows version of the example was all that was available). Looks like the author of that had struggled in the exact same spot, so I was able to see what his solution was (although, I wasn't able to locate where the solution was until I cut and paste the whole function into my source; I just had a good guess of where it was). So basically, the D example has just been ported to Derelict, which is good. Works nicely now.
The more testing I do here, the more solid the Derelict on Linux appears to be. I'm sure some bug eventually will pop up, though.
It would be great to get all this working with gdc too. I'll leave that for another time, though (haven't got gdc installed yet anyway).
- John R. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sat Feb 19, 2005 4:29 am Post subject: |
|
|
| JJR wrote: | Completed... "boing" GLFW example on Linux for Derelict. Had some nasty bug that I couldn't figure out...more hair pulling. Surprisingly, the problem was unrelated to the Derelict modules; it ended up being somehow related to D's operator precedence and casting; very strange. It didn't work exactly like it would in C.
|
Hmmph. I figured I really needed to figure out why this wasn't working the way I expected or else my faith in D would be lost... I wasn't satisfied with the other author's work-around because it indicated that he had not understood the original problem either.
After long hours and many writefln()'s later, I discovered that the issue was, once again, a silly assumption on my part; it had nothing to do with operator precedance or D casting; D behaves exactly as it should in this case and equivalently to C. The problem had to do with an incorrect constant value within an expression: MAX_RAND for the rand() function. The C system has this one defined while the D system does not. Finding the correct value (int.max) and adding it to the D program corrected everything allowing the D program to operate without any annoying workarounds.
Heh... all this writing might as well be a blog, eh? Not very useful to anybody.
Oh well, at least it shows I'm keeping busy.
- John R. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sun Feb 20, 2005 12:12 am Post subject: |
|
|
| JJR wrote: |
Heh... all this writing might as well be a blog, eh? Not very useful to anybody.
Oh well, at least it shows I'm keeping busy. |
Cut it out! You're showing me up! 
Atually, it's good to jot this stuff down somewhere. For me at least. I've found that the act of condensing your trials and tribulations into something others will find legible actually helps you to think about the problem more. Then once you've solved it, the postmortem is a record for you and anyone else who might run across a similar problem in the future. So I would say it is rather useful |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sun Feb 20, 2005 11:09 pm Post subject: |
|
|
| aldacron wrote: | | Cut it out! You're showing me up! |
He he. I'm afraid I'd have a long way to go before that happens. I don't know how long I can keep this up.
| aldacron wrote: | | Atually, it's good to jot this stuff down somewhere. For me at least. I've found that the act of condensing your trials and tribulations into something others will find legible actually helps you to think about the problem more. Then once you've solved it, the postmortem is a record for you and anyone else who might run across a similar problem in the future. So I would say it is rather useful |
You're right. It's therapeutic. As I've worked out more of these problems, I have run across errors in the D implementation too. So at least it contributes to debugging the compiler, although I don't particularly like wrestling with such a two-tier debugging session.
- John R. |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
