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

Derelict crashes when compiled as shared library

 
Post new topic   Reply to topic     Forum Index -> Derelict
View previous topic :: View next topic  
Author Message
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Tue Nov 25, 2008 3:59 pm    Post subject: Derelict crashes when compiled as shared library Reply with quote

Been reasearching why for a while and got to thinking ...

Code:

extern (C) {
 typedef int function(Uint32) pfSDL_Init;
 pfSDL_Init SDL_Init;
}


then in libSDL.so there is an SDL_Init.

when building as a shared library SDL_Init will be exported as a symbol inside the libDerelict.so and when trying to call it it calls into null data.

Those lines EVERYWHERE in Derelict needs to look as so insted:

Code:

extern (C) {
 typedef int function(Uint32) pfSDL_Init;
}

pfSDL_Init SDL_Init;

then youve got the C calling conversion on pfSDL_Init and SDL_Init is not exported as a C symbol Smile

if you dont want to do this yourself i be glad to lend a hand Smile


Last edited by MrSunshine on Tue Nov 25, 2008 5:13 pm; edited 3 times in total
Back to top
View user's profile Send private message
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Tue Nov 25, 2008 4:09 pm    Post subject: Reply with quote

this can be a LDC related problem tho, gonna talk with the devs to see if its supposed to behave like this at all .. as long as its not a function it feels like it should not export it ... but i might be wrong Smile
Back to top
View user's profile Send private message
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Tue Nov 25, 2008 5:09 pm    Post subject: Reply with quote

According to the devs its behaving as it should be and the typedef way adds alot of bloat, this way also works

Code:

extern(C) {
 alias int function(Uint32) pfSDL_Init;
}
pfSDL_Init SDL_Init;


that works fine and does not add SDL_Init as a symbol inside the library or whatever you build Smile And it reduces the resulting file size signficantly Smile
Back to top
View user's profile Send private message
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Wed Nov 26, 2008 1:53 pm    Post subject: changes Reply with quote

here is the changes that ive made, all files should be converted to using alias insted.

I need osmeone to test this stuff with more major applications then my test app Smile Also static builds etc might be good to test? (dsss bud, rebuild etc).

Heres the gains: less bloat, from 10mb release file size down to 3 without stripping, from 4 or so to 1.6 when stripped!

download it here, tell me if the link doesnt work
http://www.megaupload.com/?d=P8STR7N7

btw, the -no-dynamic-export flag that you use to compile it, does that make it not crash in say SDL_Init etc? if so i guess that what that flag does is not export symbols ? In that case this version should fix that problem also (no such flag for LDC, its only tested with ldc so far)

Anyways, i hope the changes are good enough to be commited if they fix some stuff its just great Smile Its a great library Smile

included is also a build script for LDC to build a shared library libDerelict.so just call ./build-me.sh in the dir you extracted it all to Smile
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Wed Nov 26, 2008 10:56 pm    Post subject: Re: Derelict crashes when compiled as shared library Reply with quote

MrSunshine wrote:
Been reasearching why for a while and got to thinking ...

Code:

extern (C) {
 typedef int function(Uint32) pfSDL_Init;
 pfSDL_Init SDL_Init;
}


then in libSDL.so there is an SDL_Init.


I think you're missing the purpose of Derelict. Are you linking to libSDL? If so, don't. Derelict loads libSDL automatically when you call DerelictSDL.load. You should never, ever, ever link to any of the libraries Derelict binds to.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Thu Nov 27, 2008 4:07 am    Post subject: Reply with quote

I do not, but when i compile SDL_Init gets exported by the compiler, so there will be a SDL_Init symbol in the library. So even when ive loaded libSDL using DerelictSDL.load() it seems to point to bogus data.

Ahh the example might have been miss leading, im not linking to libSDL.so but without this fix to the libraries derelict keep crashing on me as soon as i call any function that has been loaded, dunno if its the runtime loader that gets confused when calling the function as there is an actual symbol inside derelict that is called SDL_Init ... there shouldnt be if im not mistaking.

so i guess as there is actualy a symbol called SDL_Init inside the library, the application will call that symbol insted of the pointer to the function in the library and there is the problem .. as far as i know there shouldnt be a symbol SDL_Init exported inside the application there should be a D type with the C calling conversion to point to the C library function, not an actualy C function exported in the application, or am i wrong ?

and like i said, you've had problems with derelict withtout the -no-export-dynamic flag provided right? well there is no such flag for LDC so i cannot stop the compiler/linker from exporting this symbol to the world like you can with say GDC.

here is from rebuilds help:
-no-export-dynamic do not export dynamic symbols. Dynamic symbols are
exported by default on POSIX to support .so files

so its exactly the thing im talking about, with that flag you do exactly the thing ive done in code here insted to eliminate the need to use the flag, ive merly stopped the symbols from being exported as non rebuild etc users cant use the flag .. how are they supposed to be able to use the lib? Smile Do some reasearch on it and you will see that my way is the highway and it works fine, reduces the size of the lib and is just plain good ;=)

Anyways, have a good day and hope to hear from you soon Smile
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Thu Nov 27, 2008 7:15 pm    Post subject: Reply with quote

MrSunshine wrote:

here is from rebuilds help:
-no-export-dynamic do not export dynamic symbols. Dynamic symbols are
exported by default on POSIX to support .so files

so its exactly the thing im talking about, with that flag you do exactly the thing ive done in code here insted to eliminate the need to use the flag, ive merly stopped the symbols from being exported as non rebuild etc users cant use the flag .. how are they supposed to be able to use the lib? Smile Do some reasearch on it and you will see that my way is the highway and it works fine, reduces the size of the lib and is just plain good ;=)


I've never understood why the -no-export-dynamic is needed when building a static library anyway. Derelict was never intended to be built as a shared library. Frankly, I don't see the point.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Thu Nov 27, 2008 7:44 pm    Post subject: Reply with quote

MrSunshine wrote:
According to the devs its behaving as it should be and the typedef way adds alot of bloat, this way also works

Code:

extern(C) {
 alias int function(Uint32) pfSDL_Init;
}
pfSDL_Init SDL_Init;


that works fine and does not add SDL_Init as a symbol inside the library or whatever you build Smile And it reduces the resulting file size signficantly Smile


It looks like this will work without the alias, as well. Simply:

Code:

extern(C)
{
int function(Uint32) SDL_Init;
}


It has the same effect on the size of the output, though I've not tried to execute anything yet. Makes perfect sense, of course, now that I think about it. Putting all of those typedefs in the bindings was done without thinking, since that's how I'd always done it in C.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Fri Nov 28, 2008 3:10 am    Post subject: Reply with quote

but that will be a symbol that is supposed to be linked against the library right?

what the alias does if im not mistaking is defining int function(Uint32) pfSDL_Init to have a C calling conversion and then you declare it as a D type outside of the extern(C) block so ther will be no chance to clutter the symbols in the symbol table? im not realy sure here but thats how i think Smile
Back to top
View user's profile Send private message
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Fri Nov 28, 2008 3:33 am    Post subject: Reply with quote

aldacron wrote:
MrSunshine wrote:
According to the devs its behaving as it should be and the typedef way adds alot of bloat, this way also works

Code:

extern(C) {
 alias int function(Uint32) pfSDL_Init;
}
pfSDL_Init SDL_Init;


that works fine and does not add SDL_Init as a symbol inside the library or whatever you build Smile And it reduces the resulting file size signficantly Smile


It looks like this will work without the alias, as well. Simply:

Code:

extern(C)
{
int function(Uint32) SDL_Init;
}


It has the same effect on the size of the output, though I've not tried to execute anything yet. Makes perfect sense, of course, now that I think about it. Putting all of those typedefs in the bindings was done without thinking, since that's how I'd always done it in C.


tested with just


Code:

extern(C)
{
int function(Uint32) SDL_Init;
}


and that crashes as the symbols are exported with that also built both as dynamic and shared library.. so my guess is that you go with the way i said,


Code:

extern(C)
{
alias int function(Uint32) fpSDL_Init;
}
fpSDL_Init SDL_Init;


and it will work fine as that will not export any symbols just set fpSDL_Init to have a C calling conversion Smile
Back to top
View user's profile Send private message
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Fri Nov 28, 2008 3:49 am    Post subject: Reply with quote

been testing some, strange thing is that the libs built with dsss and i compile my app with dsss doesnt crash on me even with the old way in there, but the libs libDerelictSDL.a etc has the SDL_Init etc symbols in them i guess this is a problem that arises on diferent machines? . .some work some doesnt am i right?
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Fri Nov 28, 2008 6:02 am    Post subject: Reply with quote

MrSunshine wrote:
been testing some, strange thing is that the libs built with dsss and i compile my app with dsss doesnt crash on me even with the old way in there, but the libs libDerelictSDL.a etc has the SDL_Init etc symbols in them i guess this is a problem that arises on diferent machines? . .some work some doesnt am i right?


You're confusing me now. Was the crash happening when you were building the Derelict libs as shared libraries, static libraries, or both? You were using Rebuild directly, rather than DSSS?

And I'm really confused about the exported symbols. Why would symbols exported from one library clash with another that isn't even linked with?
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
MrSunshine



Joined: 21 Jan 2008
Posts: 12

PostPosted: Fri Nov 28, 2008 6:54 am    Post subject: Reply with quote

Tried both static and shared.

with my own buildscript (included in the file i posted before) it crashes, with dsss build it doesnt crash, its very strange, even if i link it by hand later it doesnt crash ... so dsss must be doing something more when it builds it or something Smile

Anyways like i said, your way your trying to do it now (when trying to do it right) seems to be wrong, i dont feel like the SDL_Init etc symbols should be exported and i fear you might have same problem like before with the -no-export-dynamic for some people ... as it looked like it was a random thing before almost? Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Derelict 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