| View previous topic :: View next topic |
| Author |
Message |
clayasaurus
Joined: 21 May 2004
Posts: 857
|
 Posted: Wed Jun 08, 2005 11:10 am Post subject: mini linux fix for dmd .126 |
 |
|
If you don't want to get this linker error...
| Code: |
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../libphobos.a(linux.o)(.data+0xc): multiple definition of `RTLD_NOW'
derelict/util/loader.o(.data+0x0): first defined here
collect2: ld returned 1 exit status
|
then in derelict.util.loader, change the following lines (around 65)...
| Code: |
else version(linux)
{
alias void* HMODULE;
extern(C)
{
// this is now defined in the latest phobos linux lib, so declaring it again gives a linker error
const int RTLD_NOW = 0x00002;
void* dlopen(char* path, int mode);
int dlclose(void* hlib);
void* dlsym(void* hlib, char* symbolName);
}
|
to
| Code: |
else version(linux)
{
private import std.c.linux.linux; // <-- added import, includes the RTLD_NOW declaration that is now in phobos
alias void* HMODULE;
extern(C)
{
// removed definition here
void* dlopen(char* path, int mode);
int dlclose(void* hlib);
void* dlsym(void* hlib, char* symbolName);
}
|
edit: changed import to private import
Last edited by clayasaurus on Wed Jun 08, 2005 5:50 pm; edited 1 time in total |
|
| Back to top |
|
 |
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Jun 08, 2005 3:19 pm Post subject: |
|
|
It's probably better to make those definitions private to the module. That saves having to add another phobos dependency to the module. The less dependence on phobos the better, I think (although I see std.string is already in there).
We'll see what Mike says on this one.
-JJR |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Wed Jun 08, 2005 5:49 pm Post subject: |
|
|
yes, I agree it should be private, since it only uses that definition in that one file. *changing code in my first post*
you could even use
std.c.linux.linux.RTLD_NOW and not import at all |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Jun 08, 2005 6:05 pm Post subject: |
|
|
| clayasaurus wrote: | yes, I agree it should be private, since it only uses that definition in that one file. *changing code in my first post*
|
Actually I meant make all the definitions private: RTLD_NOW and the dl functions and avoid using std.c.linux.linux altogether. That way, if phobos is ever replaced with another "standard" library, the change won't affect derelict.
| Quote: | you could even use
std.c.linux.linux.RTLD_NOW and not import at all |
?
Don't you have to import std.c.linux.linux to use its RTLD_NOW? That's new to me.
-JJR |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Wed Jun 08, 2005 8:01 pm Post subject: |
|
|
| JJR wrote: | It's probably better to make those definitions private to the module. That saves having to add another phobos dependency to the module. The less dependence on phobos the better, I think (although I see std.string is already in there).
We'll see what Mike says on this one. |
Considering that Phobos is supposed to be D's standard library, why even contemplate avoiding dependencies upon it? On the one hand, that's like a Java programmer avoiding the standard Java APIs (which is heresy!). But on the other, Phobos is not in the best of shape right now. Type declarations keep showing up randomly (such as COLORREF in std.c.windows.windows, and now this), some of the modules are rather subpar (such as std.loader), and it's all in a state of flux. And then there's GDC compatability, something I'd like to work on in the future.
While it's tempting to say that we should avoid Phobos as much as possible, I don't think we should. It's meant to be the standard, and therefore should be used. I think we should only resort to custom solutions when something is broken or doesn't do what we want it to (such as std.loader).
So in this case, I think we should keep the linux. But I do agree that any local declarations should be private.
By the way, Clay, your version looks to be outdated. I removed that HMODULE alias some time ago. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Wed Jun 08, 2005 9:49 pm Post subject: |
|
|
| JJR wrote: |
Don't you have to import std.c.linux.linux to use its RTLD_NOW? That's new to me.
|
Yea, it is weird. But it works : ) I'm not sure if it only works for libraries or not though, havn't really used it, just found it by mistake.
| JJR wrote: |
Actually I meant make all the definitions private: RTLD_NOW and the dl functions and avoid using std.c.linux.linux altogether. That way, if phobos is ever replaced with another "standard" library, the change won't affect derelict.
|
Humm... I tried putting the 'private' keyword infront of RTLD_NOW and I still get the same error. This isn't a compiler conflict error, it is a linker error. Even when you have it declared as private, it has conflicts because that same symbol is already defined in phobos, and we have to link with phobos. So, hum, I don't believe we have much choice anyway.
Unless I still don't quite understand 
| aldacron wrote: |
By the way, Clay, your version looks to be outdated. I removed that HMODULE alias some time ago.
|
I don't like to change derelict's unless there is a fix I need or I'm going to release some code. But I made sure to check the svn trunk to see if RTLD_NOW would be a problem with the current version, ahh wait a second, the fix is already in  Now I can't be too sure, oh well.
Have a g'night yall! Happy D programming! |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Jun 08, 2005 10:42 pm Post subject: |
|
|
| aldacron wrote: | | Considering that Phobos is supposed to be D's standard library, why even contemplate avoiding dependencies upon it? On the one hand, that's like a Java programmer avoiding the standard Java APIs (which is heresy!). But on the other, Phobos is not in the best of shape right now. Type declarations keep showing up randomly (such as COLORREF in std.c.windows.windows, and now this), some of the modules are rather subpar (such as std.loader), and it's all in a state of flux. And then there's GDC compatability, something I'd like to work on in the future. |
The reason I say avoid Phobos, Mike, is mostly because of the horrible experiences I've been having with it (on linux, though; not win32). There are several wierd symbol clash problems that pop up at the most inconvenient times... not necessarily in Derelict, but in other projects I've been working on. So I have a natural inclination to avoid using it for anything except basic tasks (writefln, format, file, etc). In Derelict's case, I thought it was a sound idea simply because the library doesn't make much use of phobos in the first place, other than for basic compiler dependencies.
| aldacron wrote: | While it's tempting to say that we should avoid Phobos as much as possible, I don't think we should. It's meant to be the standard, and therefore should be used. I think we should only resort to custom solutions when something is broken or doesn't do what we want it to (such as std.loader).
|
Okay... as long as you are satisfied, I'm satisfied.
| aldacron wrote: | So in this case, I think we should keep the linux. But I do agree that any local declarations should be private.
|
Hmmm... apparently making it private is not solving clay's problems? Strange. Oh... it looks like his Derelict is outdated.
-JJR
Last edited by JJR on Wed Jun 08, 2005 10:54 pm; edited 1 time in total |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Jun 08, 2005 10:51 pm Post subject: |
|
|
| clayasaurus wrote: | Humm... I tried putting the 'private' keyword infront of RTLD_NOW and I still get the same error. This isn't a compiler conflict error, it is a linker error. Even when you have it declared as private, it has conflicts because that same symbol is already defined in phobos, and we have to link with phobos. So, hum, I don't believe we have much choice anyway.
Unless I still don't quite understand |
Well, the reason they conflict is probably because RTLD_NOW was declared within the extern(C) block. That typically strips away any namespace differentiation. So you are right. One would have to move the RTLD_NOW declaration outside the extern(C) block in order for it to coexist with the std.c.linux.linux one in the library. Or we can just follow your original suggestion: ditch the declarations and use std.c.linux.linux! 
| claysaurus wrote: | I don't like to change derelict's unless there is a fix I need or I'm going to release some code. But I made sure to check the svn trunk to see if RTLD_NOW would be a problem with the current version, ahh wait a second, the fix is already in Now I can't be too sure, oh well.
|
So that fixes it? It works now?
| claysaurus wrote: | | Have a g'night yall! Happy D programming! |
Hey, you too, clay!
-JJR |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Wed Jun 08, 2005 11:10 pm Post subject: |
|
|
| JRR wrote: |
So that fixes it? It works now?
|
I just updated to the lastest and greatest to see what's up.
I got this error
"Failed to load proc glXGetProcAddress from shared library libGL.so.1"
So I used derelict's selective mechanism loading to fix it. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Jun 09, 2005 1:17 am Post subject: |
|
|
Oh bother. I'll take a look at it and see what's up.
Thanks!
-JJR |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Jun 09, 2005 3:02 am Post subject: |
|
|
Okay... this is getting annoying. I've had nothing but troubles with linking for the last little while on my system. Now I can't even do it with derelict libraries. What am I doing wrong?! I don't recall having so much trouble with this before!
I've built the derelict GL and Util libraries using the included makefile.
Then I go to try to compile the example:
| Code: | | dmd example.d -I../lib/DerelictUtil ../lib/libderelictUtil.a ../lib/libderelictGL.a |
But it refuses to link because it can't find the symbols for the derelictUtil library!
A similar problem has been plaguing me on another project. What the heck is going on? I must have a muddled mind because I can't see what the problem is.
-JJR
(BTW, I tried to post the error message but this PHP board tried to parse it for some reason and refused to post). |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Jun 09, 2005 3:28 am Post subject: |
|
|
Oops! Strange, I forgot to add -L-ldl... should probably add it to the pragma.
Error messages certainly gave no clue to that mistake.  |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Jun 09, 2005 3:46 am Post subject: |
|
|
Claysaurus,
example.d in the DerelictGL directory runs fine. It displays no errors. Apparently all symbols are loaded. Output:
| Code: | | Successfully loaded the OpenGL shared library |
-JJR |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Thu Jun 09, 2005 9:24 am Post subject: |
|
|
| I don't believe it is a problem with Derelict, but a problem that my driver doesn't have glXGetProcAddress for some reason, so I used derelicts selective loading process to skip it and it works fine. |
|
| 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
