Re: gtk and newlib

[Shaun Jackman <sjackman gmail com>]

I found the call that instructs glib to use my malloc and free:
		GMemVTable memvtable = {
			.malloc = malloc,
			.realloc = realloc,
			.free = free };
		g_mem_set_vtable( &memvtable);
So, that should resolve the issue of two heaps.

I'm stuck with the threading problem now. Can I simply use
pthread_create instead of g_thread_create? What exactly do the calls
to g_thread_init and gdk_threads_init accomplish? I have only one
thread accessing gdk, so I'm not worried about protecting concurrent
accesses to the gdk objects. Are these calls strictly necessary?

I've found that calling gtk_init is causing my program to crash.
Unfortunately, gdb is only giving me gobbly gook for a stack trace.
Here's my program initialisation though, for what it's worth.

		g_mem_set_vtable( &memvtable);
		g_thread_init( NULL);
		gdk_threads_init();
		gtk_init( NULL, NULL); // dies here
		drawing_area = gtk_drawing_area_new();

I know this is pretty esoteric and the proper answer is most likely
simply "Don't mix glibc and newlib, no good can come of it.", but if
the two can be made to co-exist, I'd like to figure out how.

Cheers!
Shaun
 
On Thu, 23 Dec 2004 14:06:35 -0800, Shaun Jackman <sjackman gmail com> wrote:
> I'm porting some embedded code to a Linux host, and I'm using gtk to
> emulate the LCD of the embedded device. The embedded code uses some
> specific features of newlib that are not in glibc, so I'm linking
> against newlib specifically. However, the gtk shared library I'm using
> is linked against glibc and I'm disinclined to relink gtk against
> newlib.
> 
> As I see it, there are at least two major areas of contention.
> 1. there are two heaps
> 2. there are two threading libraries
> 
> As long as I avoid the g_thread_* functions I should be able to avoid
> the second problem, but all the *_new functions that call g_malloc and
> glibc's malloc might cause me trouble. Can I instruct g_malloc to use
> my (i.e. newlib's) malloc and not glibc's?
> 
> Thanks,
> Shaun