Re: GNAT 3.14p and Red Hat 7.2

[KennethNelson@attbi.com (Ken Nelson)]

Mark Johnson <mark_h_johnson@raytheon.com> wrote in message news:<3C9F40A2.5AF3920D@raytheon.com>...
> Ken Nelson wrote:
> > 
> > GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2).  Has anyone
> > ported it to Red Hat 7.2?  If not, can someone from ACT comment on how
> > much work this would be and the best way(s) to perform a port?
> > 
> > Ken
> 
> I guess I don't understand the question. We have been using 3.14a (as
> well as 3.15w, 3.15a,...) for some time on both RH 7.1 and 7.2 systems
> (building applications & running them) without any problems at all.
> Install it, change your path, and go. I could guess at the problem you
> are having but perhaps you could elaborate :-) some more.
>   --Mark

Well, since your a _paying_ customer, it _should_ work for you.   ;-) 


In the GNAT 3.14p announcement thread...

http://groups.google.com/groups?hl=en&threadm=5ee5b646.0202030611.1df3899a%40posting.google.com&rnum=1&prev=/groups%3Fq%3Dannounce%2Bgnat%2B3.14p%2Bgroup:comp.lang.ada%26hl%3Den%26selm%3D5ee5b646.0202030611.1df3899a%2540posting.google.com%26rnum%3D1


...the following exchange took place between John English and Robert
Dewar:


John English <je@brighton.ac.uk> wrote in message news:<3C63B527.ABA4F1A7@brighton.ac.uk>...


> Wouldn't it make more sense to target a new GNAT version 
> to the current Red Hat version rather than one that's 
> about a year out of date?


The 3.14p sources were frozen some time ago, when Red Hat
version 7 was not in wide use. The current version of GNAT (e.g. the
sources at gnu.org) are indeed targetted for more
up to date versions. It is up to you whether you want to
operate at the bleeding edge with software that has not
been tested in the field extensively (the GNAT 5 version
at gnu.org), or you want to use a version that has been
extensively tested in the field (the 3.14p distribution).
But you can't have it both ways, if you want something that
is absolutely up to date, it will not have been extensively
tested. That's the way things are  :-)



Indicating that if I simply run GNAT 3.14p on Red Hat 7.2, it will
probably "go bump in the night" at a bad time (that never happens at a
good time).  So, having some time and interest, I decided to attempt
building the compiler from its sources.


I have a working copy of GNAT 3.13p and gcc 2.8.1

[ken@linux gcc-2.8.1-gnat-3.14p]$ gnatmake -v

GNATMAKE 3.13p  (20000509) Copyright 1995-2000 Free Software
Foundation, Inc.
Usage: gnatmake  opts  name  {[-cargs opts] [-bargs opts] [-largs
opts]}

[ken@linux gcc-2.8.1-gnat-3.14p]$ gcc -v
Reading specs from /home/free_sw/apps/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/specs
gcc version 2.8.1


I have done the following:

1.  Unpacked gcc-2.8.1 source
2.  Copied the GNAT 3.14p src/ada directory into the gcc 2.8.1
directory
3.  Applied the gcc-281.dif patches
4.  Touched cstamp-h.in
5.  Did not see any specific instructions for this target
6.  Touched treeprs.ads a-[es]info.h nmake.ad[bs] in ada directory
7.  Ran GCC's configure script with no parameters
8.  Successfully ran: make CC=gcc CFLAGS="-O2" LANGUAGES="c ada gcov"
9.  Successfully ran: make CC=gcc CFLAGS="-O2" LANGUAGES="c ada gcov"
bootstrap
10. However, make CC=gcc CFLAGS="-O2" gnattools  produces:

../xgcc -B../  -DIN_GCC   -O2   -o ../gnatmem b_gnatmem.o gnatmem.o
memroot.o a-gmem.o a-adaint.o a-argv.o a-cio.o a-cstrea.o a-exit.o
a-final.o a-init.o a-raise.o a-sysdep.o ada.o a-comlin.o a-except.o
a-filico.o a-finali.o a-flteio.o a-inteio.o a-ioexce.o a-stream.o
a-tags.o a-textio.o a-tiflau.o a-tigeau.o a-tiinau.o a-tiocst.o gnat.o
g-casuti.o g-hesora.o g-htable.o g-os_lib.o gnatvsn.o interfac.o
i-cstrea.o system.o s-assert.o s-except.o s-exctab.o s-exngen.o
s-exnllf.o s-fatllf.o s-ficobl.o s-fileio.o s-finimp.o s-finroo.o
s-imgbiu.o s-imgenu.o s-imgint.o s-imgllb.o s-imglli.o s-imgllu.o
s-imgllw.o s-imgrea.o s-imguns.o s-imgwiu.o a-traceb.o s-traceb.o
s-mastop.o s-parame.o s-powtab.o s-secsta.o s-sopco3.o s-sopco4.o
s-sopco5.o s-stache.o s-stalib.o s-stoele.o s-stratt.o s-strops.o
s-soflin.o s-unstyp.o s-valllu.o s-vallli.o s-valint.o s-valrea.o
s-valuns.o s-valuti.o ../prefix.o \
	-laddr2line -lbfd -liberty 
a-adaint.o: In function `__gnat_tmp_name':
a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use
`mkstemp'
g-os_lib.o: In function `gnat__os_lib__create_temp_file':
g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use
`mkstemp'
a-gmem.o: In function `__gnat_gmem_a2l_initialize':
a-gmem.o(.text+0xc4): undefined reference to `convert_addresses'
a-gmem.o: In function `__gnat_gmem_read_bt_frame':
a-gmem.o(.text+0x20d): undefined reference to `convert_addresses'
make[2]: *** [../gnatmem] Error 1
make[2]: Leaving directory `/home/free_sw/gcc-2.8.1-gnat-3.14p/ada'
make[1]: *** [gnatmem] Error 2
make[1]: Leaving directory `/home/free_sw/gcc-2.8.1-gnat-3.14p'
make: *** [gnattools] Error 2



The function convert_addresses (from RH 6.2) appears to no longer be
apart of the binutils package in Red Hat 7.2.  The previous two errors
can be fairly easily worked-around, but I don't recall exactly what I
did to do that (in a previous build).


Having run into a non-trival issue (probably not the last) which has
been solved by ACT, I decided to appeal to c.l.a. to see if someone
might provide some assistance/guidance - instead of just blindly,
laboriously, slaying dead bugs that I reincarnated.



Ken