Mac support for gtkD

gtkD-Mac.patch

(that "win32" and "x11" functions fail to load shouldn't be too surprising)

The failed functions look similar to the ones that fail on my system. except for the x11 functions. That shouldn't be a problem as long as the program you're running doesn't use them.

Replying to afb:

The program crashes on startup, in "g_malloc0" or similar threaded allocation attempt.

If this only happens with the TestWindow? demo it might be a gdc bug (Bugzilla: 1751) witch causes the TestWindow? demo to segfault when build with gdc 0.24

That seems to be the same thing, yes. I'm using r199 but same thing happens.

true
Error: AssertError Failure test.d(8) test is only null in gdc 0.24

(GDC pre-release 0.25 svn r199 that is, not gtkd's changeset 199)

Still crashes in the same place when using GDC 0.23.

#0  0x001241d9 in g_malloc0 ()
#1  0x00000246 in ?? ()
#2  0x00b61ed7 in g_thread_init_glib ()
#3  0x0097c820 in g_thread_init ()
#4  0x00042456 in gtk.GtkD.GtkD.initMultiThread(char[][]) (args={length = 1, ptr = 0xc00550}) at src/gtk/GtkD.d:161

Replying to afb:

Still crashes in the same place when using GDC 0.23. {{{ #0 0x001241d9 in g_malloc0 () #1 0x00000246 in ?? () #2 0x00b61ed7 in g_thread_init_glib () #3 0x0097c820 in g_thread_init () #4 0x00042456 in gtk.GtkD.GtkD.initMultiThread(char[][]) (args={length = 1, ptr = 0xc00550}) at src/gtk/GtkD.d:161 }}}

I am able to reproduce this on linux when i use "-q,-rdynamic" when linking the executable.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7dc8ae0 (LWP 7976)]
0x082b6655 in g_malloc ()

(gdb) backtrace
#0  0x082b6655 in g_malloc ()
#1  0xb7f56253 in g_mutex_new_posix_impl () from /usr/lib/libgthread-2.0.so
#2  0xb76e3499 in g_thread_init_glib () from /usr/lib/libglib-2.0.so.0
#3  0xb7f5653a in g_thread_init () from /usr/lib/libgthread-2.0.so
#4  0x081c6aea in _D7gthread6Thread6Thread4initFPS4gtkc12gthreadtypes16GThreadFunctionsZv (vtable=0x0) at gthread/Thread.d:160
#5  0x081a35fc in _D3gtk4GtkD4GtkD15initMultiThreadFAAaZ

I wouldn't know, GTK works fine from D when using the bindings instead of function pointers...

The -rdynamic switch somehow messes with the dynamically loaded symbols in gtkD.

If you are using a similar switch on OSX then that is probably causing the segfault. i asume you are using -Wl,-undefined,dynamic_lookup since they are in the makefile, i haven't found what they do.

for a description of the -rdynamic switch:

-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.

and for -export-dynamic

--export-dynamic
When creating a dynamically linked executable, add all symbols to the dynamic symbol table. The dynamic symbol table is the set of symbols which are visible from dynamic objects at run time. If you do not use this option, the dynamic symbol table will normally contain only those symbols which are referenced by some dynamic object mentioned in the link. If you use dlopen to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself.

i found the meaning of -undefined,dynamic_lookup:

-undefined treatment

Specifies how undefined symbols are to be treated. Options are: error, warning, suppress, or dynamic_lookup. The default is error.

I don't know how this relates to the -rdynamic flag on linux, what heapen when you don't pass those flags to the linker?

and for dynamic_lookup

-undefined dynamic_lookup, if a symbol is not found, we will link anyway and hope to find it later in a dynlib.

new patch posted by afb on the D newsgroup

new patch posted by afb on the D newsgroup

Having problems uploading the patch.

It seems it's only a problem with viewing the patch online.