[parisc-linux] gcc-cvs problem

[parisc-linux] gcc-cvs problem

[joel.soete]

Hi all,

I try to rebuild toolchain on my new b2000 with last binutils-cvs glic-2.2.5
(debian) and last gcc-cvs (aka 3.2?).

The procedure works fine with gcc-cvs dated 20020424 but now it failed on glibc
compile with following message:
/Develop/parisc-linux/parisc-SN32/bin/hppa-linux-gcc
../sysdeps/unix/sysv/linux/init-first.c -c -O2 -Wall -Winline
-Wstrict-prototypes -Wwrite-strings -g      -I../include -I.
-I/Develop/parisc-linux/build/glibc/csu -I.. -I../libio 
-I/Develop/parisc-linux/build/glibc -I../sysdeps/hppa/elf
-I../linuxthreads/sysdeps/unix/sysv/linux/hppa
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread
-I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv
-I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/hppa
-I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
-I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet
-I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/hppa/fpu
-I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic/elf
-I../sysdeps/generic  -nostdinc -isystem
/Develop/parisc-linux/parisc-SN32/lib/gcc-lib/hppa-linux/3.2/include -isystem
/Develop/parisc-linux/src/linux/include -D_LIBC_REENTRANT -include
../include/libc-symbols.h     -DHAVE_INITFINI -o
/Develop/parisc-linux/build/glibc/csu/init-first.o
In file included from ../include/pthread.h:1,
                 from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
                 from ../sysdeps/generic/ldsodefs.h:34,
                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                 from ../sysdeps/unix/sysv/linux/init-first.c:32:
../linuxthreads/sysdeps/pthread/pthread.h:163: parse error before "__thread"
../linuxthreads/sysdeps/pthread/pthread.h:165: `pthread_create' declared as
function returning a function
../linuxthreads/sysdeps/pthread/pthread.h:165: warning: function declaration
isn't a prototype
../linuxthreads/sysdeps/pthread/pthread.h:166: parse error before "void"
../linuxthreads/sysdeps/pthread/pthread.h:591: storage class specified for
parameter `type name'
In file included from ../linuxthreads/sysdeps/pthread/pthread.h:655,
                 from ../include/pthread.h:1,
                 from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
                 from ../sysdeps/generic/ldsodefs.h:34,
                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                 from ../sysdeps/unix/sysv/linux/init-first.c:32:
../linuxthreads/sysdeps/unix/sysv/linux/bits/sigthread.h:36: storage class
specified for parameter `type name'
make[2]: *** [/Develop/parisc-linux/build/glibc/csu/init-first.o] Error 1
make[2]: Leaving directory `/Develop/parisc-linux/src/glibc/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/Develop/parisc-linux/src/glibc'
make: *** [all] Error 2

### Thu May 30 19:04:35 2002 ###

Any idea?

Joel

ps: glibc tree was prepare in accordance with Carlos howto.

-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[John David Anglin]

> In file included from ../include/pthread.h:1,
>                  from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
>                  from ../sysdeps/generic/ldsodefs.h:34,
>                  from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
>                  from ../sysdeps/unix/sysv/linux/init-first.c:32:
> ../linuxthreads/sysdeps/pthread/pthread.h:163: parse error before "__thread"

See <http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01780.html> for fix.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-cvs problem

[joel.soete]

Hi Dave,

It seems to be well comited in last cvs update this morming I got in
src/gcc/gcc/fixinc/inclhack.def:
...
/*
 * __thread is now a keyword.
 */
fix = {
    hackname  = thread_keyword;
    files     = "pthread.h";
    files     = "bits/sigthread.h";
    select    = " __thread([,)])";
    c_fix     = format;
    c_fix_arg = " __thr%1";

    test_text =
        "extern int pthread_create (pthread_t *__restrict __thread,\n"
        "extern int pthread_kill (pthread_t __thread, int __signo);\n"
        "extern int pthread_cancel (pthread_t __thread);";
};
...

But do not seems to be applied as I got the same error?

What do I wrong or forget to do?

Thanks for add help,
    Joel


Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> > In file included from ../include/pthread.h:1,
> >                  from
> ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
> >                  from ../sysdeps/generic/ldsodefs.h:34,
> >                  from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
> >                  from ../sysdeps/unix/sysv/linux/init-first.c:32:
> > ../linuxthreads/sysdeps/pthread/pthread.h:163: parse error before
> "__thread"
> 
> See <http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01780.html> for fix.
> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc.ca
> National Research Council of Canada              (613) 990-0752 (FAX:
> 952-6605)
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 
> 


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[John David Anglin]

> It seems to be well comited in last cvs update this morming I got in
> src/gcc/gcc/fixinc/inclhack.def:
> ...
> /*
>  * __thread is now a keyword.
>  */

> But do not seems to be applied as I got the same error?
> 
> What do I wrong or forget to do?

You should see the following in your build output:

Applying thread_keyword           to pthread.h
Fixed:  pthread.h

A fixed pthread.h should appear in the {build}/gcc/include directory.
This seems to work ok for me in a native hppa-linux build.  However,
it appears that you are trying to do a cross build.  If the header
is not being fixed, you will need to examine your build log carefully
to determine why the fix isn't being done or doesn't work.

Dave
--
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-cvs problem

[Joel Soete]

John David Anglin wrote:
>>It seems to be well comited in last cvs update this morming I got in
>>src/gcc/gcc/fixinc/inclhack.def:
>>...
>>/*
>> * __thread is now a keyword.
>> */
> 
> 
>>But do not seems to be applied as I got the same error?
>>
>>What do I wrong or forget to do?
> 
> 
> You should see the following in your build output:
> 
> Applying thread_keyword           to pthread.h
> Fixed:  pthread.h
> 
> A fixed pthread.h should appear in the {build}/gcc/include directory.
> This seems to work ok for me in a native hppa-linux build.  However,
> it appears that you are trying to do a cross build.

AFAIK gcc bootstrap does not work for hppa?

> If the header
> is not being fixed, you will need to examine your build log carefully
> to determine why the fix isn't being done or doesn't work.
> 

I will have a detailed look but as newbee in gcc stuff it will take a time.

Thank again for attention and help,
	Joel

Re: [parisc-linux] gcc-cvs problem

[John David Anglin]

> I will have a detailed look but as newbee in gcc stuff it will take a time.

If you manually execute the failing compilation command changing '-c'
to '-E', this will generate the cpp processed output for the compilation
source file.  Inspection of this output should allow you to see exactly
which include files have been loaded and the result of all macro expansions.

There may be a problem with the include hack or possibly an unfixed
version of the pthread.h header is being loaded.  Gcc puts fixed include
directories in ${prefix}/lib/${target}/${gcc_version}/include.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-cvs problem

[joel.soete]

Dave,

Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> > It seems to be well comited in last cvs update this morming I got in
> > src/gcc/gcc/fixinc/inclhack.def:
> > ...
> > /*
> >  * __thread is now a keyword.
> >  */
> 
> > But do not seems to be applied as I got the same error?
> > 
> > What do I wrong or forget to do?
> 
> You should see the following in your build output:
> 
> Applying thread_keyword           to pthread.h
> Fixed:  pthread.h

It stand well in my log files and here is the result:
in {build}/gcc/include/pthread.h
...
/* Create a thread with given attributes ATTR (or default attributes
   if ATTR is NULL), and call function START_ROUTINE with given
   arguments ARG.  */
extern int pthread_create (pthread_t *__restrict __thr,
                           __const pthread_attr_t *__restrict __attr,
                           void *(*__start_routine) (void *),
                           void *__restrict __arg) __THROW;
...

Which seems to be the desired patch?

Hmm... In what changing parameter name from __thread to __thr in such function
prototype does matter (exepted if there is a border effect with some #define
else where)? [afaik this name doe not matter for a C compiler?]

So I will have to go further to analyse precompile results.

See you next,
    Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[John David Anglin]

> /* Create a thread with given attributes ATTR (or default attributes
>    if ATTR is NULL), and call function START_ROUTINE with given
>    arguments ARG.  */
> extern int pthread_create (pthread_t *__restrict __thr,
>                            __const pthread_attr_t *__restrict __attr,
>                            void *(*__start_routine) (void *),
>                            void *__restrict __arg) __THROW;
> ...
> 
> Which seems to be the desired patch?

Yes.

> Hmm... In what changing parameter name from __thread to __thr in such function
> prototype does matter (exepted if there is a border effect with some #define
> else where)? [afaik this name doe not matter for a C compiler?]

Changing the name doesn't matter in a C function prototype.  The bug in the
system header is that __thread is now a reserved language keyword.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-cvs problem

[joel.soete]

Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> > I will have a detailed look but as newbee in gcc stuff it will take a
> time.
> 
> If you manually execute the failing compilation command changing '-c'
> to '-E', this will generate the cpp processed output for the
> compilation
> source file.

Hey I also had to do it when I tried and succed to port f2c with bcc 31 (ten
years ago already ;)

>  Inspection of this output should allow you to see exactly
> which include files have been loaded and the result of all macro
> expansions.

and here is the only pthread_create expansion I found in the output file:
# 163 "../linuxthreads/sysdeps/pthread/pthread.h"
extern int pthread_create (pthread_t *__restrict __thread,
                           __const pthread_attr_t *__restrict __attr,
                           void *(*__start_routine) (void *),
                           void *__restrict __arg) ;

So I will change manually __thread by __thr and see.

I also find glibc cvs and co and the new version of 

${src}/glibc/linuxthreads/sysdeps/pthread/pthread.h replace also __thread by
__threadp. Curious?

Joel

-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[joel.soete]

Dave,

I really have no chance with this b2000:
I broken first my install and now it makes a HPMC in the middle of binutils
build and the pim info are not clear :((

So I will have to ask to HP to analyse those pim and eventually repare it.
(I hoppe we have a maintenance contract for this server)

Joel

Quoting joel.soete@freebel.net:

> Dave,
> 
> Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:
> 
> > > It seems to be well comited in last cvs update this morming I got
> in
> > > src/gcc/gcc/fixinc/inclhack.def:
> > > ...
> > > /*
> > >  * __thread is now a keyword.
> > >  */
> > 
> > > But do not seems to be applied as I got the same error?
> > > 
> > > What do I wrong or forget to do?
> > 
> > You should see the following in your build output:
> > 
> > Applying thread_keyword           to pthread.h
> > Fixed:  pthread.h
> 
> It stand well in my log files and here is the result:
> in {build}/gcc/include/pthread.h
> ...
> /* Create a thread with given attributes ATTR (or default attributes
>    if ATTR is NULL), and call function START_ROUTINE with given
>    arguments ARG.  */
> extern int pthread_create (pthread_t *__restrict __thr,
>                            __const pthread_attr_t *__restrict __attr,
>                            void *(*__start_routine) (void *),
>                            void *__restrict __arg) __THROW;
> ...
> 
> Which seems to be the desired patch?
> 
> Hmm... In what changing parameter name from __thread to __thr in such
> function
> prototype does matter (exepted if there is a border effect with some
> #define
> else where)? [afaik this name doe not matter for a C compiler?]
> 
> So I will have to go further to analyse precompile results.
> 
> See you next,
>     Joel
> 
> 
> -------------------------------------------------
> This mail sent through Tiscali Webmail (http://webmail.tiscali.be)
> 
> 


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[John David Anglin]

> I really have no chance with this b2000:
> I broken first my install and now it makes a HPMC in the middle of binutils
> build and the pim info are not clear :((

I'd try a new kernel first.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-cvs problem

[joel.soete]

Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> > I really have no chance with this b2000:
> > I broken first my install and now it makes a HPMC in the middle of
> binutils
> > build and the pim info are not clear :((
> 
> I'd try a new kernel first.

Very strange behaviour: 
with some difficulties I reach to restart a kernel then I launch  my toolchain
script (which failled because of __therad problem), I change the faulty header
and finaly relaunch script which failled in a tar xjf (some time during the
first extract of binutils, some time during the second extract of gcc32) what
ever the kernel I used 2.4.18-pa24 2.4.18-pa24+lvm1.0.4 2.4.19-pre8-pa29?.

But thanks to the console logs grab with minicom I reach to notice the "BUG":

Debian GNU/Linux 3.0 palx2000 ttyS0

palx2000 login:

kernel BUG at superio.c:109!
WARNING! Stack pointer and cr30 do not correspond!
Dumping virtual address stack instead

Dumping Stack from 0x2ee00000 to 0x2ee00bc0:
...

What could the reason why the tar xjf is successfull a first time and when it is
relaunched, it fails? Ext3 fs (I am not sure how can I change back to ext2) bash
(which other sh may I try) ?


Joel

PS: after a cleanpim it seems to be easiest to reboot?

-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[joel.soete]

I not yet quiet sure that is not an hardware problem but I reboot on the kernel
2.4.18-pa29 and an hpmc occurs after an some minutes without doing anything else
then let it run for itself?

Then I reboot on hpux (10.20), unfortunately no problem occurs during the 4
hours it runs.

So now I reboot in su mode to move back ext3 to ext2 my all fs.
Then reboot in mu. It works and it is on going to recompile toolchain but it is
now so slow (even badly then a 712/80).

Is there other thing to do than backup, re-mkfs, restore to recover some
performance?

Thanks in advance for advice,
    Joel

Quoting joel.soete@freebel.net:

> Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:
> 
> > > I really have no chance with this b2000:
> > > I broken first my install and now it makes a HPMC in the middle of
> > binutils
> > > build and the pim info are not clear :((
> > 
> > I'd try a new kernel first.
> 
> Very strange behaviour: 
> with some difficulties I reach to restart a kernel then I launch  my
> toolchain
> script (which failled because of __therad problem), I change the faulty
> header
> and finaly relaunch script which failled in a tar xjf (some time during
> the
> first extract of binutils, some time during the second extract of gcc32)
> what
> ever the kernel I used 2.4.18-pa24 2.4.18-pa24+lvm1.0.4
> 2.4.19-pre8-pa29?.
> 
> But thanks to the console logs grab with minicom I reach to notice the
> "BUG":
> 
> Debian GNU/Linux 3.0 palx2000 ttyS0
> 
> palx2000 login:
> 
> kernel BUG at superio.c:109!
> WARNING! Stack pointer and cr30 do not correspond!
> Dumping virtual address stack instead
> 
> Dumping Stack from 0x2ee00000 to 0x2ee00bc0:
> ...
> 
> What could the reason why the tar xjf is successfull a first time and
> when it is
> relaunched, it fails? Ext3 fs (I am not sure how can I change back to
> ext2) bash
> (which other sh may I try) ?
> 
> 
> Joel
> 
> PS: after a cleanpim it seems to be easiest to reboot?
> 
> -------------------------------------------------
> This mail sent through Tiscali Webmail (http://webmail.tiscali.be)
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 
> 


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[joel.soete]

Hi Dave,

Quoting joel.soete@freebel.net:

> Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:
> 
> > > I really have no chance with this b2000:
> > > I broken first my install and now it makes a HPMC in the middle of
> > binutils
> > > build and the pim info are not clear :((
> > 
> > I'd try a new kernel first.
> 
> Very strange behaviour: 
> with some difficulties I reach to restart a kernel then I launch  my
> toolchain
> script (which failled because of __therad problem), I change the faulty
> header
> and finaly relaunch script which failled in a tar xjf (some time during
> the
> first extract of binutils, some time during the second extract of gcc32)
> what
> ever the kernel I used 2.4.18-pa24 2.4.18-pa24+lvm1.0.4
> 2.4.19-pre8-pa29?.
> 
> But thanks to the console logs grab with minicom I reach to notice the
> "BUG":
> 
> Debian GNU/Linux 3.0 palx2000 ttyS0
> 
> palx2000 login:
> 
> kernel BUG at superio.c:109!
> WARNING! Stack pointer and cr30 do not correspond!
> Dumping virtual address stack instead
> 
> Dumping Stack from 0x2ee00000 to 0x2ee00bc0:
> ...
> 
> What could the reason why the tar xjf is successfull a first time and
> when it is
> relaunched, it fails? Ext3 fs (I am not sure how can I change back to
> ext2) bash
> (which other sh may I try) ?
> 

Well what ever was the fs type (ext2 or ext3) the problem was the same;
apparently until the fs was clearly corrupted and required a fsck. Everything
seems to come back Ok.

So finaly I had to replace __thread to _thr in some glibc headers (already
changed in the glibc cvs actually change __thread to __threadp) and now the
toolchaine compiles successfully for gcc-3.2.

The kernel still compiles and boot well :) 
But the inetd connection also still there :( (hope kdb will help)

Thanks again for help,
    Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[joel.soete]

Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> > It seems to be well comited in last cvs update this morming I got in
> > src/gcc/gcc/fixinc/inclhack.def:
> > ...
> > /*
> >  * __thread is now a keyword.
> >  */
> 
> > But do not seems to be applied as I got the same error?
> > 
> > What do I wrong or forget to do?
> 
> You should see the following in your build output:
> 
> Applying thread_keyword           to pthread.h
> Fixed:  pthread.h
> 
> A fixed pthread.h should appear in the {build}/gcc/include directory.
> This seems to work ok for me in a native hppa-linux build.


With build toolchain procedure I build well a cross compiler hppa to hppa?

Also I would like to compare the results with a gcc hppa-linux native build when
I compile the kernel with gcc-3.1 (or 3.2) and see if the same network problem
occurs.

But in that case I ignore what parameters I would have to use to configure and
compile gcc natively. Can you still help me?

Thanks in advance,
    Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-cvs problem

[John David Anglin]

> But in that case I ignore what parameters I would have to use to configure and
> compile gcc natively. Can you still help me?

If you are using a 64-bit machine, you will have to specify "--host".  You
probably also want to specify "--prefix".  So, in your build directory,

${gcc_source_directory}/configure --prefix=${somewhere} --host=hppa-linux

This will configure the build for everything.  If you want just C, specify
"--enable-languages=c".  You may also want to specify where the assembler
and linker are if you don't want the defaults.  Type

${gcc_source_directory}/configure --help

for more option information.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)