View previous topic :: View next topic |
Author |
Message |
fred
Joined: 09 Feb 2005 Posts: 5
|
Posted: Wed Feb 09, 2005 7:36 am Post subject: gdc |
|
|
Did anybody compiled DUI using GDC instead of DMD?
Oryginal makefile is almost unusable -- to many modyfications are required in to many places...
At this point I compiled dool library, and fighting with dui and HelloWorld, but getting tired with thouse human unfriendly messages from gcc linker....
Andrzej Borsuk.. |
|
Back to top |
|
|
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Wed Feb 09, 2005 8:31 am Post subject: Re: gdc |
|
|
fred wrote: | Did anybody compiled DUI using GDC instead of DMD? |
Yes, it was done before, check here:
http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/942
I didn't do it yet.
fred wrote: | Oryginal makefile is almost unusable |
I believe you can also find a modified Makefile.
If you do it can you send me all the changes and steps so I integrate that on the distribution?
Ant |
|
Back to top |
|
|
fred
Joined: 09 Feb 2005 Posts: 5
|
Posted: Thu Feb 10, 2005 5:01 am Post subject: Re: gdc |
|
|
Thanks!
I'm checking this now..
Best regards,
Andrzej Borsuk |
|
Back to top |
|
|
fred
Joined: 09 Feb 2005 Posts: 5
|
Posted: Thu Feb 10, 2005 9:08 am Post subject: Re: gdc |
|
|
Ant wrote: |
If you do it can you send me all the changes and steps so I integrate that on the distribution?
Ant |
I haven't make a big progress for now...
I have replaced Makefile with one ugly Build.sh wich do something like this:
Code: |
mkdir -p $DUI_OUT/$dir
echo Dir: $dir
for i in $dir/*.d
do
echo File: $i
gdc -c \
-o$DUI_OUT/$dir/$(basename $i .d).o \
-I$DOOL_SRC \
$i \
|| echo error!
done
|
At this moment I concentrate only on DUI (and dool) itself. Everything but EventHandler.d compiles cleanly...
Quote: |
File: event/EventHandler.d
dui/Widget.d:373: template instance EventHandlerR!(Widget ,EventButton ) forward reference to template
dui/Widget.d:374: template instance EventHandlerR!(Widget ,EventButton ) forward reference to template
(..)
|
Patches for EventHandler found on sf.net looks very outdated.... and there are already applied to DUI dirtribution?
Those errors looks strange for me.. Widget.d compiled cleanly, the same like others files...
Little update...
I have compiled every *.d file using:
Code: |
for i in dglib ddi dango event dui
do
gdc -c -fall-sources -I$DOOL_SRC $i/*.d
done
|
it looks like for EventHandler.d its important to be compiled with option -fall-sources (everything at one command with event/*.d as argument)
Tomorow I'll try to compile HelloWorld and if it will work I'll try to create some real makefiles in place of this scripts...
Best Regards,
Andrzej Borsuk |
|
Back to top |
|
|
fred
Joined: 09 Feb 2005 Posts: 5
|
Posted: Fri Feb 11, 2005 5:10 am Post subject: Re: gdc |
|
|
fred wrote: |
Tomorow I'll try to compile HelloWorld and if it will work I'll try to create some real makefiles in place of this scripts...
|
Umpfff.... Its still a hard work....
I have recompiled whole library by hand to get full debug info.
HelloWorld now compiles without errors but strange thing happened to libdui.a After creation whole library as *.o files I had to recompile dango/*.d once again -- without it I have compilation errors? Strange....
Everything looks but hw failed to run (coredumped)
I have compiled it with command
Code: |
gdc -O0 -g HelloWorld.o \
-lgc -lm -ldl -lpthread \
libdui.a libdool.a \
`pkg-config --libs gtk+-2.0` \
`pkg-config --libs gthread-2.0`
|
and in debugger session I have something like this:
Quote: |
Starting program: /home/fred/Projekty/testy/d/a.out
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 12004)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 12004)]
0x00000000 in ?? ()
(gdb) backtrace
#0 0x00000000 in ?? ()
#1 0x08092409 in _D3dui5Label5Label13getSelectableFZb (this=@0x40822fc0) at dui/Label.d:340
#2 0x08097bac in _D3dui6Widget6Widget5_ctorFPS3def5Types9GtkObjectZC3dui6Widget6Widget (this=@0x40822fc0, gtkObject=0x812f908)
at dui/Widget.d:565
#3 0x08098d31 in _D3dui6Widget6Widget5_ctorFPS3def5Types9GtkWidgetZC3dui6Widget6Widget (this=@0x40822fc0, gtkWidget=0x812f908)
at dui/Widget.d:894
#4 0x08096d40 in _D3dui4Misc4Misc5_ctorFPS3def5Types9GtkWidgetZC3dui4Misc4Misc (this=@0x40822fc0, gtkWidget=0x812f908) at dui/Misc.d:65
#5 0x08091c3b in _D3dui5Label5Label5_ctorFPS3def5Types9GtkWidgetZC3dui5Label5Label (this=@0x40822fc0, gtkWidget=0x812f908) at dui/Label.d:91
#6 0x08091cad in _D3dui5Label5Label5_ctorFC4dool6String6StringZC3dui5Label5Label (this=@0x40822fc0, str=@0x40820f00) at dui/Label.d:116
#7 0x08091d03 in _D3dui5Label5Label5_ctorFAaZC3dui5Label5Label (this=@0x40822fc0, str={_a = 11, _b = 0x80b5998 "Hello World"})
at dui/Label.d:125
#8 0x0808a993 in _D2hw10HelloWorld10HelloWorld5_ctorFZC2hw10HelloWorld10HelloWorld ()
#9 0x0808aa08 in _Dmain ()
#10 0x080a9f98 in _D6dmain29true_mainFiPPaZi (argc=1, argv=0xbffff544) at internal/dmain2.d:102
#11 0x080a9f1e in main (argc=0, argv=0x0) at internal/dmain2.d:49
|
I have no idea how to fix it....
UPDATE
madness...
above listing shows that program calls function at address 0x0?
the fatal cal is in Label.d:340
because this line contains two function calls I have split it into two and then recompiled...
Code: |
bit getSelectable()
{
GtkLabel *l = gtkW();
printf("gtkW=?p\n", l);
return gtk_label_get_selectable(l)==0?false:true;
}
|
... and now coredumped even before calling this function. This time it was recursive call of dump() in Container.d:117..
I have modified this function, commenting out everything inside:
Code: |
void dump()
{
printf("dum, dum dumm\n");
/*
GtkContainer* gtkContainer = cast(GtkContainer*)gtkW();
super.dump();
(...)
|
and now I have another coredump
Quote: |
$ ./a.out
dum, dum dumm
gtkW=0xe
Naruszenie ochrony pamiÄci (core dumped)
$ gdb a.out core
(..)
#0 0x401a255d in gtk_label_get_selectable (label=0xe) at gtklabel.c:2485
2485 g_return_val_if_fail (GTK_IS_LABEL (label), FALSE);
(gdb) backtrace
#0 0x401a255d in gtk_label_get_selectable (label=0xe) at gtklabel.c:2485
#1 0x0808747a in _D3dui5Label5Label13getSelectableFZb (this=@0x40822fc0) at dui/Label.d:342
#2 0x0808b0d4 in _D3dui6Widget6Widget5_ctorFPS3def5Types9GtkObjectZC3dui6Widget6Widget (this=@0x40822fc0, gtkObject=0x8120908)
at dui/Widget.d:565
#3 0x0808c259 in _D3dui6Widget6Widget5_ctorFPS3def5Types9GtkWidgetZC3dui6Widget6Widget (this=@0x40822fc0, gtkWidget=0x8120908)
at dui/Widget.d:894
#4 0x0808a268 in _D3dui4Misc4Misc5_ctorFPS3def5Types9GtkWidgetZC3dui4Misc4Misc (this=@0x40822fc0, gtkWidget=0x8120908)
at dui/Misc.d:65
#5 0x08086c8b in _D3dui5Label5Label5_ctorFPS3def5Types9GtkWidgetZC3dui5Label5Label (this=@0x40822fc0, gtkWidget=0x8120908)
at dui/Label.d:91
#6 0x08086cfd in _D3dui5Label5Label5_ctorFC4dool6String6StringZC3dui5Label5Label (this=@0x40822fc0, str=@0x40820f00)
at dui/Label.d:116
#7 0x08086d53 in _D3dui5Label5Label5_ctorFAaZC3dui5Label5Label (this=@0x40822fc0, str={_a = 11, _b = 0x80a8ec8 "Hello World"})
at dui/Label.d:125
#8 0x080815e3 in _D2hw10HelloWorld10HelloWorld5_ctorFZC2hw10HelloWorld10HelloWorld ()
#9 0x08081658 in _Dmain ()
#10 0x0809d4c8 in _D6dmain29true_mainFiPPaZi (argc=1, argv=0xbffff534) at internal/dmain2.d:102
#11 0x0809d44e in main (argc=135346088, argv=0x81137a8) at internal/dmain2.d:49
|
For me it looks like whole gdc is just too unstable to build any code...
I have compiler based on gcc-3.4.3, at the weekend I'll try to build gdc based on gcc-3.3. Maybe this will help, maybe not..... |
|
Back to top |
|
|
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Fri Feb 11, 2005 10:51 am Post subject: Re: gdc |
|
|
fred wrote: | For me it looks like whole gdc is just too unstable to build any code... |
I thought it would be the time to start trying it - based on the reports on the d.gnu group.
I wan't to give it a try but I'm just too busy with other projects.
Ant |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Feb 11, 2005 1:42 pm Post subject: |
|
|
I'm slowly plugging away at a loader linking version of DUI (similar to the way derelict works or mango.icu). The advantage of doing it this way is that it cleans up a bunch of source... kind of simplifies it in some respects (and certainly simplifies the compile process). Perhaps once I'm done this, we'll see how gdc responds to it. On the other hand this might do nothing to fix what gdc is choking on right now. The advantage of re-programming DUI this way is primarily felt on the Win32 platform, but we'll see if there's any good side-effects on other platforms too.
Converting to the dynamic link system is a long, tedious task. Don't expect to see it done any time soon (I never realized how much work Ant had put into this project... pheww!)
- John R. |
|
Back to top |
|
|
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Fri Feb 11, 2005 2:10 pm Post subject: |
|
|
somehere along the way I created an automatic tool to generate DUI code from the Gtk docs.
Ant |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Feb 11, 2005 2:23 pm Post subject: |
|
|
Hello Ant,
I dropped it for a bit, but picked it up again because the idea still seemed attractive (especially for windows).
I'll send you a sample of the structure I'm looking at. I may change it once it's all put together, but the basic idea will remain as well as the loading process. So the as long as the automated tool fills up the function pointer list and function name list for each external library, small changes later should not matter.
If you could automate the process that would be wonderful. I don't have enough experience in that regard to know how; I tried with regex's and python but after several hours, gave up. It looked to me that a tool would have to implement a full parser to get it to work. We'll see.
I've completed the pango function loader class. I'll forward it to you shortly.
Later,
John R. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Feb 11, 2005 2:29 pm Post subject: |
|
|
Ant wrote: | somehere along the way I created an automatic tool to generate DUI code from the Gtk docs.
Ant |
Sorry Ant,
I messed with your post, accidently. I forgot that I had admin privileges here and clicked "edit" on your post without thinking (I was thinking I had pressed "quote"). Soon I had completely rewritten your message.... Argh. This is all that remains of it.
So sorry!
- John R. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Feb 11, 2005 2:30 pm Post subject: |
|
|
Ant wrote: | somehere along the way I created an automatic tool to generate DUI code from the Gtk docs.
Ant |
This is an excellent idea! I hadn't thought of that. Using the doc specs would certainly work in this case too. It should be a fairly simple process to fill the function lists using a doc parser. |
|
Back to top |
|
|
fred
Joined: 09 Feb 2005 Posts: 5
|
Posted: Sat Feb 12, 2005 5:32 am Post subject: Re: gdc |
|
|
Ant wrote: | fred wrote: | For me it looks like whole gdc is just too unstable to build any code... |
I thought it would be the time to start trying it - based on the reports on the d.gnu group.
I wan't to give it a try but I'm just too busy with other projects.
Ant |
I'm not give up yet I'm still trying....
But now I'm working on my home computer. I had to build whole D-Language enviorment first. I have some ancient gdb without threads support, so garbage collector's thread messing everything... etc, etc..
At this moment I have two ideas whats is going on:
First, is possible problem with garbage collector -- I have discovered that option -lgc links with _external_ gc found in my /usr/local not from gcc distribuition (boehem-gc-6.4). On d.gnu group I have found posting saying that whole program should build without -lgc option.
Second idea is about bug in dynamic linking -- every time segfault arives when program calls external function from .so file
If I find something I'll write here.. |
|
Back to top |
|
|
|