a tisket - NO TASKet

a tisket - NO TASKet

[alan walkington]

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??????

Alan Walkington
walky@netmagic.net

Re: a tisket - NO TASKet

[David C. Hoos, Sr.]

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.

Baasket case : Re: a tisket - NO TASKet

[walkington]

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

a) rts-native, 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 as specified below, recompiled
and re-archived the object files. Now the linker is choking:

]$ amake test2.adb
gcc -c -g -I/usr/src/gnat-3.10p-i386-linux-bin/rts-fsu/adainclude
-I/usr/src/X11Ada/ada test2.adb
gnatbind -aO./ -aO/usr/src/gnat-3.10p-i386-linux-bin/rts-fsu/adalib
-aO/usr/src/X11Ada/ada -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.
>
>


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

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

[David C. Hoos, Sr.]

walkington@my-dejanews.com wrote in message
<6vo2ml$im1$1@nnrp1.dejanews.com>...
>Original problem: internal sigfault in runtime when trying to use any
tasking.
>setup:  redhat5.1, gnat-3_10p-i386-linux-bin_tar.gz
>
>a) rts-native, 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 as specified below,
recompiled
>and re-archived the object files. Now the linker is choking:
>
>]$ amake test2.adb
>gcc -c -g -I/usr/src/gnat-3.10p-i386-linux-bin/rts-fsu/adainclude
>-I/usr/src/X11Ada/ada test2.adb
>gnatbind -aO./ -aO/usr/src/gnat-3.10p-i386-linux-bin/rts-fsu/adalib
>-aO/usr/src/X11Ada/ada -I- -x test2.ali
>error: "test2.adb" must be recompiled ("s-osinte.ads" has been modified)
>gnatmake: *** bind failed.
>
>sigh .. all/any assistance appreciated


Did you execute the following script, as instructed?  If you had done so,
everything would have been recompiled in the rts.  You should do this at
least in the rts you are going to use -- preferably in both.

#!/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.

Then, go on with the symbolis lik,s etc., as described.

By the way, what is "amake?"

>
>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.
>>
>>
>
>
>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum