RE: [GNAT] native/fsu thread

RE: [GNAT] native/fsu thread

[Wilhelm Spickermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 533 bytes --]

Hello,

On 23-Aug-99 Foolish Pagan wrote:
> 
> Hello,
> 
> I have problem installing and running gnat-3.11p on my Linux box.
> ...

The redhat rpms of the "Linux for Ada Team":
http://www.cl.cam.ac.uk/~mgk25/linux-ada/
will do the job. 

gnat-3.11p-1-15.i386.rpm and gnat-3.11p-devel-1-15.i386.rpm contain
Gnat, Glade and Asis. They have solved the problem by installing a
totally independent gcc and gdb (gnatgcc and gnatgdb) -- so there
won�t be any conflicts with egcs or gcc needed to compile the kernel.

Regards,
Wilhelm

Re: [GNAT] native/fsu thread

[Robert Dewar]

In article <7pqais$j5s$1@justice.csc.cuhk.edu.hk>,
  Foolish Pagan <parngon@kernel.linux.org.hk> wrote:
>
> Hello,
>
> I have problem installing and running gnat-3.11p on my Linux
box.
> Here is the config:


I would suggest sending gnat specific questions like this
to the gnat chat list, where there are many people who are
knowledgable about GNAT who do not read CLA>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: [GNAT] native/fsu thread

[Simon Wright]

Foolish Pagan <parngon@kernel.linux.org.hk> writes:

>     patch -p0 < ../gnat-3.11p-src/src/gcc-*.dif

I don't think the instructions call for the wildcard here, do they?
If there are more than 2 files, shouldn't you be using the appropriate
one?

> 	./configure --enable-thread --with-elf --prefix=/opt/gnat

I don't think the instructions call for --enable-thread --with-elf,
do they?

(I am a Slackware user, libc5, and never had any trouble with building
GNAT except when I tried to include c++)

Re: [GNAT] native/fsu thread

[jerry]

Simon Wright <simon@pogner.demon.co.uk> wrote:

: (I am a Slackware user, libc5, and never had any trouble with building
: GNAT except when I tried to include c++)

YES! I knew there had to be more of us... Also proud owner of a vi
reference mug :-)

-- 
-- Jerry van Dijk  | email: jdijk@acm.org 
-- Team Ada        | web:   http://stad.dsl.nl/~jvandyk
-- Leiden, Holland | Paris, France

[GNAT] native/fsu thread

[Foolish Pagan]

Hello,

I have problem installing and running gnat-3.11p on my Linux box.
Here is the config:

  Redhat 6.0 (glibc 2.1 + egcs-1.1.2)
  gcc-2.8.1
  gnat-3.11p

The problem is that since I don't have the egcs source tree,
I download the gcc-2.8.1 tar ball. I've also use gnat-3.11p binary
pre-build for glibc (the ftp site didn't specify which version
of glibc it built on) as the previous version of GNAT.

I then extract all the tar balls, do a simple installation of the
binary dist of gnat-3.11p, and point the gcc to that one instead
of my original one (egcs). I followed the instruction from the
gnat-3.11p-src and did the following:

	cd gcc-2.8.1
    patch -p0 < ../gnat-3.11p-src/src/gcc-*.dif
	mv ../gnat-3.11p-src/src/ada .
	cd ada
	touch treeprs.ads a-[es]info.h nmake.ad[bs]
	cd ..
	./configure --enable-thread --with-elf --prefix=/opt/gnat
	make CC=gcc CFLAGS="-O2" LANGUAGES="ada"
	make CC=gcc CFLAGS="-O2" LANGUAGES="ada" bootstrap
	make CC=gcc CFLAGS="-O2" gnattools
	make CC=gcc CFLAGS="-O2" GNATLIBCFLAGS="-O2" gnatlib     ---------(1)
	make install LANGUAGES="ada"

Actually the build is fine, and I know that this build will use native
thread instead of fsu one. The problem is that when I run the example
program diners (hello and other do really work), the prompt seems to
me that it is not responding... Doing a strace on this I found that
the program is causing a seg fault...

--------------------------------------------------------------------------------
execve("./diners", ["diners"], [/* 61 vars */]) = 0
brk(0)                                  = 0x80811ec
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
mmap(0, 18403, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)                                = 0
open("/lib/libpthread.so.0", O_RDONLY)  = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 67204, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40019000
mprotect(0x40022000, 30340, PROT_NONE)  = 0
mmap(0x40022000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8000)
= 0x40022000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 974392, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002a000
mprotect(0x40110000, 32312, PROT_NONE)  = 0
mmap(0x40110000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xe5000) = 0x40110000
mmap(0x40115000, 11832, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40115000
close(3)                                = 0
munmap(0x40014000, 18403)               = 0
personality(PER_LINUX)                  = 0
getpid()                                = 3128
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=2040*1024, rlim_max=RLIM_INFINITY}) = 0
getpid()                                = 3128
uname({sys="Linux", node="kernel.linux.org.hk", ...}) = 0
SYS_174(0x20, 0xbffff040, 0, 0x8, 0x20) = 0
SYS_174(0x21, 0xbffff034, 0, 0x8, 0x21) = 0
SYS_174(0x22, 0xbffff040, 0, 0x8, 0x22) = 0
SYS_175(0, 0xbffff2a0, 0, 0x8, 0)       = 0
SYS_174(0x4, 0xbffff180, 0, 0x8, 0x4)   = 0
SYS_174(0x6, 0xbffff174, 0, 0x8, 0x6)   = 0
SYS_174(0x8, 0xbffff168, 0, 0x8, 0x8)   = 0
SYS_174(0xb, 0xbffff184, 0, 0x8, 0xb)   = 0
SYS_174(0x7, 0xbffff178, 0, 0x8, 0x7)   = 0
SYS_174(0x8, 0xbffff070, 0xbfffefe4, 0x8, 0x8) = 0
SYS_174(0x4, 0xbffff070, 0xbfffefe4, 0x8, 0x4) = 0
SYS_174(0xb, 0xbffff070, 0xbfffefe4, 0x8, 0xb) = 0
SYS_174(0x1, 0, 0xbffff074, 0x8, 0x1)   = 0
SYS_174(0x2, 0, 0xbffff074, 0x8, 0x2)   = 0
SYS_174(0x3, 0, 0xbffff074, 0x8, 0x3)   = 0
SYS_174(0x4, 0, 0xbffff074, 0x8, 0x4)   = 0
SYS_174(0x5, 0, 0xbffff074, 0x8, 0x5)   = 0
SYS_174(0x6, 0, 0xbffff074, 0x8, 0x6)   = 0
SYS_174(0x7, 0, 0xbffff074, 0x8, 0x7)   = 0
SYS_174(0x8, 0, 0xbffff074, 0x8, 0x8)   = 0
SYS_174(0x9, 0, 0xbffff074, 0x8, 0x9)   = 0
SYS_174(0xa, 0, 0xbffff074, 0x8, 0xa)   = 0
SYS_174(0xb, 0, 0xbffff074, 0x8, 0xb)   = 0
SYS_174(0xc, 0, 0xbffff074, 0x8, 0xc)   = 0
SYS_174(0xd, 0, 0xbffff074, 0x8, 0xd)   = 0
SYS_174(0xe, 0, 0xbffff074, 0x8, 0xe)   = 0
SYS_174(0xf, 0, 0xbffff074, 0x8, 0xf)   = 0
SYS_174(0x10, 0, 0xbffff074, 0x8, 0x10) = 0
SYS_174(0x11, 0, 0xbffff074, 0x8, 0x11) = 0
SYS_174(0x12, 0, 0xbffff074, 0x8, 0x12) = 0
SYS_174(0x13, 0, 0xbffff074, 0x8, 0x13) = 0
SYS_174(0x14, 0, 0xbffff074, 0x8, 0x14) = 0
SYS_174(0x15, 0, 0xbffff074, 0x8, 0x15) = 0
SYS_174(0x16, 0, 0xbffff074, 0x8, 0x16) = 0
SYS_174(0x17, 0, 0xbffff074, 0x8, 0x17) = 0
SYS_174(0x18, 0, 0xbffff074, 0x8, 0x18) = 0
SYS_174(0x19, 0, 0xbffff074, 0x8, 0x19) = 0
SYS_174(0x1a, 0, 0xbffff074, 0x8, 0x1a) = 0
SYS_174(0x1b, 0, 0xbffff074, 0x8, 0x1b) = 0
SYS_174(0x1c, 0, 0xbffff074, 0x8, 0x1c) = 0
SYS_174(0x1d, 0, 0xbffff074, 0x8, 0x1d) = 0
SYS_174(0x1e, 0, 0xbffff074, 0x8, 0x1e) = 0
SYS_174(0x1f, 0, 0xbffff074, 0x8, 0x1f) = 0
SYS_175(0x1, 0xbffff1d8, 0, 0x8, 0x1)   = 0
SYS_175(0x2, 0, 0xbffff2f8, 0x8, 0x2)   = 0
brk(0)                                  = 0x80811ec
brk(0x808121c)                          = 0x808121c
brk(0x8082000)                          = 0x8082000
fstat(2, {st_mode=S_ISVTX|0404, st_size=0, ...}) = 0
fstat(0, {st_mode=S_ISVTX|0404, st_size=0, ...}) = 0
fstat(1, {st_mode=S_ISVTX|0404, st_size=0, ...}) = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbffff184, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbffff064, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbfffef44, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbfffee24, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbfffed04, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbfffebe4, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbfffeac4, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbfffe9a4, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbfffe884, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---
SYS_175(0x1, 0xbfffe764, 0, 0x8, 0x1)   = 0
--- SIGSEGV (Segmentation fault) ---

** actually it loops forever here **
--------------------------------------------------------------------------------

I then try the build with fsu:

    make CC=gcc CFLAGS="-O2" GNATLIBCFLAGS="-O2" THREAD_KIND=fsu gnatlib

and diners works. However, when I tried to build glade, I learnt from
the README that on Linux, the GNAT has to be compiled in native thread.

Have anyone experience this installation config before? Please help.

Thanks in advance!


Regards,
Kit

Re: [GNAT] native/fsu thread

[Fake Pagan]

Hello,


Robert Dewar (dewar@gnat.com) wrote:
: I would suggest sending gnat specific questions like this
: to the gnat chat list, where there are many people who are
: knowledgable about GNAT who do not read CLA>

I am sorry for that. Actually I've forgot to check the general
posting policy of this group.

Anyway, thanks for all your help!


Cheers,
Kit