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

gdc

 
Post new topic   Reply to topic     Forum Index -> gtkD
View previous topic :: View next topic  
Author Message
fred



Joined: 09 Feb 2005
Posts: 5

PostPosted: Wed Feb 09, 2005 7:36 am    Post subject: gdc Reply with quote

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
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Wed Feb 09, 2005 8:31 am    Post subject: Re: gdc Reply with quote

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
View user's profile Send private message
fred



Joined: 09 Feb 2005
Posts: 5

PostPosted: Thu Feb 10, 2005 5:01 am    Post subject: Re: gdc Reply with quote

Ant wrote:

http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/942


Thanks! Very Happy
I'm checking this now..

Best regards,
Andrzej Borsuk
Back to top
View user's profile Send private message
fred



Joined: 09 Feb 2005
Posts: 5

PostPosted: Thu Feb 10, 2005 9:08 am    Post subject: Re: gdc Reply with quote

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
View user's profile Send private message
fred



Joined: 09 Feb 2005
Posts: 5

PostPosted: Fri Feb 11, 2005 5:10 am    Post subject: Re: gdc Reply with quote

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 Evil or Very Mad

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
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Fri Feb 11, 2005 10:51 am    Post subject: Re: gdc Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Fri Feb 11, 2005 1:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Fri Feb 11, 2005 2:10 pm    Post subject: Reply with quote

somehere along the way I created an automatic tool to generate DUI code from the Gtk docs.

Ant
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Fri Feb 11, 2005 2:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Fri Feb 11, 2005 2:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Fri Feb 11, 2005 2:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
fred



Joined: 09 Feb 2005
Posts: 5

PostPosted: Sat Feb 12, 2005 5:32 am    Post subject: Re: gdc Reply with quote

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 Smile 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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> gtkD 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