a Basket case -- Re: a tisket-NO TASKet

a Basket case -- Re: a tisket-NO TASKet

[alan walkington]

Original problem: internal sigfault in runtime when trying to use any
tasking.
setup:  redhat5.1, gnat-3_10p-i386-linux-bin_tar.gz

Assistance received (below) recommends a change requiring recompilation of
's-osinte.ads'.
I tried that. Results are:

a) in the native runtime (rts-native), the spec and body of 's-osinte.ads'
were created with different options
and will not compile. Spec has many more procedures specified that the body
implements.

b) I made changes to the florida state runtime (rts-fsu) as specified below,
recompiled
and re-archived the object files. Now the linker is choking:

$> gnatmake  (appropriate parameters) test2.adb
gcc -c -g -I/usr/src/gnat-3.10p-i386-linux-bin/rts-fsu/adainclude test2.adb
gnatbind -aO./ -aO/usr/src/gnat-3.10p-i386-linux-bin/rts-fsu/adalib -I- -x
test2.ali
error: "test2.adb" must be recompiled ("s-osinte.ads" has been modified)
gnatmake: *** bind failed.

sigh .. all/any assistance appreciated

Alan Walkington
walky@netmagic.net


In article <medGWu289GA.209@samson.airnet.net>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> alan walkington wrote in message <6vjpvq$fdf$1@usenet44.supernews.com>...
> >Horrors
> >
> >Redhat 5.1, intel box, latest free gnat (2.10? .. whatever).
> >
> >Attempting to execute ANY program with tasking gets a
> >  Seg fault during elaboration of  the _adainit internal
> >           >>>'system_interupt_management___elabb'<<<
> >
> >Have had no problems with anything else, but even the
> >simplest tasking example fails to execute.
> >
> >Help anyone??????
> >
> A number of people have found that this solution works for them.  The
> cause of the segmentation fault is the change of the size of sigset_t
> from 32 bits to 1024 bits.
>
> I have posted this message several times on gnat chat -- so here it is
> again:
>
> For what it's worth, Here's how I have gnat-3.10p running on RedHat 5.0.
> I did it originally with the 2.0.31 kernel, the upgraded to the 2.0.32
> kernel.
>
> The fundamental problem is that RedHat 5.0 increases the size of sigset_t
> from 32 bits to 1024 bits.
>
> To correct this problem, the file s-osinte.ads needs to be altered -- e.g.
> as follows:
>
> 591c591,593
> < type sigset_t is new unsigned_long;
>
> ---
> >    SIGSET_NWORDS : constant := 1024 / (unsigned_long'Size);
> >
> >    type sigset_t is array (1 .. SIGSET_NWORDS) of unsigned_long;
>
> Then, the adalib(s) need to be compiled -- either the native linux threads
> runtime or the Florida State University (fsu) runtime, or both.
>
> To do this I executed the following script in each adalib directory:
>
> #!/bin/tcsh -f
> foreach f (../adainclude/*.ad[bs])
>   gcc -c -O2 -gnatpga -I- $f
> end
>
> To be sure, this script re-compiles some stuff not rendered obsolete by
> the change to s-osinte.ads, but it was quicker just to recompile
> everything than to figure out what needed to be recompiled.
>
> Next, the libgnat.a archive needs to be rebuilt with something like:
>
> ar ru libgnat.a *.o, in each of the adalibs.
>
> In my case, the size of the libgnat.a file for the native rts changed as
> follows:
> -rw-r--r--   1 root     root      1747090 Feb 14 12:21 ../adalib/libgnat.a
> -rw-r--r--   1 4168     1100      1740584 Aug 24  1997
> ../adalib/libgnat.a.orig
>
> I don't remember for sure, but I don't think I manually manipulated any of
> the symbolic links related to the libraries, but at any rate, here's what
my
> /usr/lib/gcc-lib/i386-linux/2.7.2.1 directory looks like (sorry but these
> long lines may wrap in you mail client):
>
> NOTE: While the above comment about my not remembering making any
> symbolic liks is true, the evidence below suggests that I symbolically
> linked
> several files in  /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/2.7.2.1 to
the
> /usr/lib/gcc-lib/i386-linux/2.7.2.1 directory.
>
> total 2743
> lrwxrwxrwx   1 root     root           50 Feb 12 05:24 2.7.2.1 ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/2.7.2.1
> lrwxrwxrwx   1 root     root           55 Feb 12 05:24 SYSCALLS.c.X ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/SYSCALLS.c.X
> lrwxrwxrwx   1 root     root           58 Feb 20 04:22 adainclude ->
> /usr/lib/gcc-lib/i386-linux/2.7.2.1/rts-native/adainclude/
> lrwxrwxrwx   1 root     root           54 Feb 20 04:22 adalib ->
> /usr/lib/gcc-lib/i386-linux/2.7.2.1/rts-native/adalib/
> lrwxrwxrwx   1 root     root           46 Feb 12 05:24 cc1 ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/cc1
> lrwxrwxrwx   1 root     root           50 Feb 12 05:24 cc1plus ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/cc1plus
> lrwxrwxrwx   1 root     root           46 Feb 12 05:24 cpp ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/cpp
> lrwxrwxrwx   1 root     root           53 Feb 12 05:24 crtbegin.o ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/crtbegin.o
> lrwxrwxrwx   1 root     root           54 Feb 12 05:24 crtbeginS.o ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/crtbeginS.o
> lrwxrwxrwx   1 root     root           51 Feb 12 05:24 crtend.o ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/crtend.o
> lrwxrwxrwx   1 root     root           52 Feb 12 05:24 crtendS.o ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/crtendS.o
> -rwxr-xr-x   1 4168     1100      2271408 Sep 12  1997 gnat1
> lrwxrwxrwx   1 root     root           50 Feb 12 05:24 include ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/include
> -rw-r--r--   1 root     root       206902 Feb 14 10:10 libgcc.a
> -rw-r--r--   1 root     root       238346 Feb 14 10:10 libgthreads.a
> -rw-r--r--   1 root     root        74242 Feb 14 10:10 libmalloc.a
> drwxr-xr-x   4 4168     1100         1024 Aug 24  1997 rts-fsu
> drwxr-xr-x   4 4168     1100         1024 Aug 24  1997 rts-native
> lrwxrwxrwx   1 root     root           48 Feb 12 05:24 specs ->
> /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs
>
> As a further sanity check, executing "gcc -v" should result in a message
> like:
>
> Reading specs from: /usr/lib/gcc-lib/i386-linux/2.7.2.1/specs
>
> The 2.7.2.1 directory points to 2.7.2.3 because gcc 2.7.2.3 was installed
> first (as part of the Linux installation), then gnat was installed on top
of
> that -- and gnat is 2.7.2.1-based.
>
> I hope I've covered all of the bases here, as this installation is working
> fine for me.
>
> I should acknowledge that others of this group helped me when I ran into
the
> problem a few weeks ago, identifying the cause of the problem and
providing
> the broad outline of what to do.
>
> Good luck to all who have this problem.
>
> David C. Hoos, Sr.
>
>