In message <[EMAIL PROTECTED]>
Stefan Bellon <[EMAIL PROTECTED]> wrote:
> Stefan Bellon wrote:
> > 2John Tytgat wrote:
> ^
> Whatever this was, it was a mistake. ;-)
>
> > > Ah so I did try the right thing and no, -gnatdl does not give me the
> > > debug I thought it would give in this case. :-(
>
> > I suspected this. It shows the information for explicitly stated
> > dependencies in a file. But if your hello.adb is just the simple
>
> > procedure Hello is
> > begin
> > null;
> > end Hello;
>
> > then there is no gain with -gnatdl.
>
> Ok, I did some tests in the meantime and can say the following:
>
> 1) It is "just" a path lookup issue. If you copy the system ads and adb
> directories in your current working directory, then system.ads and
> other system packages you depend on in your project are found.
Indeed so. I was able to find and fix this problem. I've uploaded a new
kit with this fix at:
<URL:http://joty.drobe.co.uk/gccsdk-4.1.1.pre-rel2-20080516-c-ada-static-no-multilib.zip>
> 2) gnatmake does not work reliably yet. If you start compilation via
> gnatmake, you get:
>
> *gnatmake hello
> gcc -c } ΒΈ hello.adb
> gnatmake: error, unable to locate gcc
This is still a problem and actually a wrong code generation for nested
functions in gnatmake. I understand nested functions is a rather common
thing in Ada so this needs to be fixed if we want to include Ada in GCCSDK.
> So I sticked to
>
> *gcc -c hello.adb
>
> which worked and produced an o.hello ELF output.
Yes.
> 3) gnatmake does not find its sister programs:
>
> *gnatmake hello
> gnatbind -x hello.ali
> gnatmake: error, unable to locate gnatbind
I get now a "raised MAKE.BIND_FAILED : make.adb:1124" error and I think
this is the same problem concerning nested function & its code generation.
> Again, calling gnatbind manually works (having copied the system ali
> directory over into the current working directory previously):
>
> *gnatbind -x hello.ali
Yes.
> 4) Linking with gnatlink does not work either.
Confirmed. Not sure what this is but after the code generation problem
for nested functions is solved, who knows this will be solved as well. ;-)
Note that that it is possible to link & run the resulting Ada program on
RISC OS, by:
--8<--
gcc -o hello.o -c hello.adb
gnatbind hello.ali
gcc -c -gnatA -gnatWb -gnatiw -v -gnatws b~hello.adb
gcc -L/ADFS::MyDisc.$/Full/Path/To/!GCC/lib/gcc/arm-unknown-riscos/4.1.1/adalib
-lgnat -o hello b~hello.o hello.o
--8<--
But of course this is as demonstration only, it shouldn't be done like this.
As the kit I've made is a static build the resulting binary is quite large.
After stripping away the debug/symbol info, the resulting binary is about
321K.
> 5) What is puzzling me is, that in
> lib.gcc.arm-unknown-riscos.4/1/1.adalib.o there is only g-trasym
> present and nothing else. I would have expected that directory to be
> either fully populated with object files for the individual packages
> or completely empty, if the appropriate library is in place.
Possibly. I really don't have an answer. However, I guess all the objects
are in libgnat.a. No idea why g-trasym.o is an exception.
> Ok, that's for it now, have to do some work. Will take a closer look
> this evening if I find the time.
Thanks. I would really love to get more feedback on this new kit. ;-)
John.
--
John Tytgat, in his comfy chair at home BASS
[EMAIL PROTECTED] ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
