View previous topic :: View next topic |
Author |
Message |
hduregger
Joined: 15 Aug 2007 Posts: 11
|
Posted: Wed Apr 16, 2008 2:12 pm Post subject: FreeType segfault with DerelictFT and DWT/GTK/FT |
|
|
Hey, first of all thanks for Derelict which is very handy.
Now to the ugly part:
I am getting segmentation faults in FT_Done_Memory when loading freetype through DerelictFT and also compiling DWT into the application.
From inspecting the binary with 'ldd' I've found out that DWT dynamically links to FreeType itself (I think by linking to GTK, FreeType gets loaded too).
Weird is that the application does not segfault at the first call to FreeType but some time later inside a FreeType function. But if I don't use DWT the test application runs fine. And also DWT works fine when I don't additionally load FreeType with DerelictFT.
The debugger 'zero' says
0x0810b725 .../test <FT_Done_Memory +0x1>
at the location where it segfaults.
The test application is
Code: |
module test;
import tango.io.Stdout;
import derelict.util.exception,
derelict.freetype.ft;
// If this is commented, it works, else segfaults.
import dwt.DWT;
bool myMissingProcCallback(char[] libName, char[] procName)
{
return true;
}
int main(char[][] argv)
{
Stdout.flush(true);
// Ignore missing symbols, this is verified to work
Derelict_SetMissingProcCallback(&myMissingProcCallback);
// DerelictFT.load("/usr/lib/libfreetype.so.6.3.16");
DerelictFT.load();
Derelict_SetMissingProcCallback(null);
FT_Library library = null;
Stdout("Before").newline;
// This FT_Init_FreeType call works when no DWT stuff is compiled/linked in
// with DSSS
assert(FT_Init_FreeType !is null);
if (FT_Init_FreeType( &library ) != 0)
{
Stdout("Error").newline;
}
Stdout("Done").newline;
return 0;
}
|
Derelict is r295, DSSS is 0.75, DMD is 1.027, DWT is newest, Tango is 0.99.5 (patched with some changes in Collection to fix DMD bugs that effect DWT)
Rebuild options 'oneatatime=no' due to some issues with DWT build taking very long if set to 'yes'.
Platform is Linux (Ubuntu 7.10).
There is not much activity in #dwt but a short discussion suggested to ask here and since this seems to be linkage related I took that advice.
Any ideas what could be going on and how to fix it? |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Wed Apr 16, 2008 9:15 pm Post subject: |
|
|
I don't believe this is fixable in Derelict's current state. In the past, people have sometimes not fully understood the purpose of Derelict and linked their DerelictSDL apps to the SDL import library, resulting in segmentation faults like the one you describe. It appears that dynamically loading a library causes conflicts if that same library is loaded via a statically linked import lib. There's nothing I can do about that sort of conflict.
One solution in this case is to drop DerelictFT for your app and use a different FreeType binding, one that requires linkage to the import lib. If DWT is using FreeType internally, it must be using such a binding.
Another solution would require modification to the Derelict packages. I got it in my head some time ago to provide an alternative to use Derelict without the manual loading, requiring linkage with import libraries, i.e. just like any normal binding. It was implemented experimentally in DerelictAL, but no one was using it and no one commented on it.
It may be time to revisit this idea. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
hduregger
Joined: 15 Aug 2007 Posts: 11
|
Posted: Thu Apr 17, 2008 3:55 am Post subject: |
|
|
Thanks for explaining and the fast reply.
I'll just try to write my own bindings for the FT functions I need.
Hopefully you can add that functionality in the future of Derelict. I am sure the additional versatility will be useful in the future of D. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Thu Apr 17, 2008 4:34 am Post subject: |
|
|
I hope you see this post before you do that! I've just committed an update that will allow you to use DerelictFT with static linkage, or with the FreeType import library. To do so, you will need to compile your app with version=DerelictFT_Static. The same if you build the DerelictFT library. In your source, import derelict.freetype.ft as usual and you're done. No need to call DerelictFt.load (which won't be available anyway) and no need to link with DerelictUtil or import any of its modules.
This is completely untested and was put together inside of 20 minutes. I'm interested to hear if it works. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
Cyborg16
Joined: 28 Apr 2007 Posts: 39
|
Posted: Thu Apr 17, 2008 5:40 am Post subject: |
|
|
I think you're submission was incomplete (missing file and version statement should use brackets). But wouldn't just moving the bind functions to another module which the user can include, or not, be the simplest solution? |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Thu Apr 17, 2008 6:16 am Post subject: |
|
|
Cyborg16 wrote: | I think you're submission was incomplete (missing file and version statement should use brackets). |
Well that was silly. I forgot to add the new file. Fixed in the trunk.
Quote: | But wouldn't just moving the bind functions to another module which the user can include, or not, be the simplest solution? |
That's possible as is. To use the static style bindings without defining DerelictFT_Static, just import derelict.freetype.sftfuncs. You'll also need to import derelict.freetype.fttypes to make use of the types. Actually, I should probably make that a public import in both ftfuncs and sftfuncs.
I still want to leave the conditional compilation with derelict.freetype.ft, though. It makes things so much more convenient for packages with a large number of modules, such as DerelictGL and DerelictSDL, to have a base module that import everything. This provides for a consistent interface.
Besides, I haven't decided yet how to structure the static version for the other packages. For OpenGL it's even more complicated because it's impossible to statically link to versions higher than 1.1 on Windows. As long as the common and recommended interface for both styles will be through the base module for each package (with static linkage handled via a version=PackageName_Static for specific modules or version=Derelict_Static for all of them), then it doesn't matter how they are handled internally. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
hduregger
Joined: 15 Aug 2007 Posts: 11
|
Posted: Thu Apr 17, 2008 10:54 am Post subject: |
|
|
Thanks for doing the changes.
You still have a small typo in there:
Code: |
sftfuncs.d(79): found 'FT_List' when expecting ')'
|
and in sftfuncs.d the module declaration must be changed to this
Code: |
module derelict.freetype.sftfuncs;
|
to make it work.
But then it works smooth, yay! |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
|
Back to top |
|
|
|