[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GNAT/RTEMS hassles with bit_ada
- Date: Wed, 01 Aug 2001 07:22:54 -0500
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: GNAT/RTEMS hassles with bit_ada
lange92 at 2067.resnet.uni.edu wrote:
> Hello all,
> Well after applying the patch in the gnat-3.12p/src directory for
> gcc-281 (level p0), I managed to get the tools to compile. After that, I
> went on to build the i386-rtemself target and pc386 bsp.
If your ultimate target is the i386, then you will run into trouble
because in gcc 2.8.1 i386-rtems was coff. i386-rtems is now elf.
The linker scripts are a bit different.
> During the build
> of the bsp, I had to copy the files crti.o and crtn.o from "/usr/lib" on my
> system; crtbegin.o and crtend.o from "/usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1"
> to each of the sample test programs (hello, paranoia, ticker, unlimited,
> base_sp) built.
I recall doing a similar with some version of the native gnat binaries
to make them work on some Linux hosts.
> Having decided that I'd have to rewrite the Makefile for the
> hello_world_ada package, I chose the Makefile.score603e as a base
> makefile, made the changes at the top, and attempted to build it. The
> first time I received an error from gnatlink about the "-r" option, so
> after a quick removal of the "-bargs -r \" line from the Makefile, I
> compiled again, and received the following error:
> i365-rtemself-gcc: file path prefix: `/users/lange92/illinoiscentral/rtems-i386/pc386//lib' never used
> init.o: In function `start_gnat_main':
> /users/lange92/illinoiscentral/tools/hello_world_ada/init.c:37: undefined reference to `gnat_main'
> i386-rtemself-gnatmake: *** link failed.
> make: *** [all] Error 4
There have been changes in how gnat deals with environments that do
not have a real main.
According to the 3.13p docs, you need a "-n" option and the RTEMS thread
starting the Ada application needs to call adainit and adafinal. This
in the GNAT User's Guide.
> Again, I had to copy the files "crti.o crtn.o crtbegin.o crtend.o" to the
> hello_world_ada directory to perform a make this successful. Having to
> copy files from the base system makes me suspicious of an error in the
> installation. So this brings up a few questions:
Although it appears to be the same as what you did with the native
binary, it isn't. You are including a native Linux crt* with embedded
code and it should NOT be used with the RTEMS targets.
The root problem is that the bsp_specs and linkcmds are setup for ELF.
I THINK you can simply remove the references to them in bsp_specs and
be OK. This is because i386-rtems with gcc 2.8.1 is COFF!!! i386-rtems
with gcc 2.9x and newer is ELF.
GNAT hanging back with gcc 2.8.1 has really caused a disruption to
GNAT/RTEMS. I eagerly await them releasing a gnat for use with gcc 3.0.
This will solve these weird issues and we will include Ada in the RPMs
as soon as we can.
> 1. should I have taken the time during/before/after running the bit_ada
> script to build the rts-fsu and rts-native thread libraries?
This is a native compiler issue. Doesn't matter at all to the cross.
> 2. Question of documentation:
> is set to "yes" if you want to enable the RTEMS POSIX API
> support. At this time, this feature is not supported by the
> UNIX ports of RTEMS and is forced to "no" for those targets.
> This corresponds to the configure option --enable-posix.
> This must be enabled to support the GNAT/RTEMS run-time."
> Would linux qualify, in this case, of a UNIX port? If so, does that
> mean that linux can't host GNAT/RTEMS? Should I switch to Cygwin or
> something that's better supported that can handle the POSIX API?
You are misreading this. RTEMS is completely independent of Linux.
RTEMS can be built on any UNIX-ish environment. RTEMS may or may not
be built with support for POSIX threads, mutexes, etc. GNAT/RTEMS
assumes the underlying RTEMS was configured with --enable-posix.
The Linux environment is a great one to use as a host.
And remember -- no Linux code is in the RTEMS binary.
> 3. During the build of the tools (bit_ada) I still get errors about not
> finding the files regex.h, reg_types.h, and lc_core.h.
I don't know about this without more details.
> 4. During the bit_ada script execution, twice the script flashed a
> message about the necessity of linking with the -LLIBDIR flag, and including
> the <toolsdir>/lib directory. Does the bit_rtems script handle this, or is
> it something I need to handle myself? I didn't see anything along these
> lines in any of the documentation.
This is just a general warning that it is putting libraries places you
normally wouldn't look for them.
> 5. Any recommendations on the ideal host environment for GNAT/RTEMS? I
> would imagine that I would be able to install Cygwin or whatever without
> any difficulties if I could get this runtime to function. It may be a good
> deal more difficult to set up than our old runtime, but that one doesn't
> have anywhere near the functionality that RTEMS appears to have.
Linux is great.
> Thanks again, for all the help and words of advice and inspiration. I
> appreciate it.
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985