[parisc-linux] [2.5] next issues ...

[parisc-linux] [2.5] next issues ...

[Bjoern A. Zeeb]

Hi,

2.5.47-pa3 up and running I added my vlan interface, ssh'ed to the
host and *buff*


--- 8< 8< ---
Stack Dump:
 14db4000:

Kernel addresses on the stack:


Kernel Fault: Code=15 regs=14db4000 (Addr=4c4c4c4c)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03  00000000 10290810 101b4134 4c4c0000
r04-07  4c4c4c4c 4c4c4c4d 14db7000 14db3e48
r08-11  00000001 00000000 00000000 40018000
r12-15  14db798c 14dac290 000e7760 faf00fdc
r16-19  000e7760 ffffffe8 00000004 0000000b
r20-23  0000000b 0000000f 00000000 00000001
r24-27  106fd160 00000000 150d7000 10274010
r28-31  00000000 000b7cc1 14db4000 101b3278
sr0-3   00000000 00000632 00000000 00000632
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 101b40f0 101b40f4
 IIR: 0c821033    ISR: 00000000  IOR: 4c4c4c4c
 CPU:        0   CR30: 14dac000 CR31: 102a2000
 ORIG_R28: 00000000
--- 8< 8< ---



So I booted up again to have a look at System.map but....



--- 8< 8< ---
Checking root file system...
fsck 1.30-WIP (30-Sep-2002)
/dev/sda3 was not cleanly unmounted, check forced.
...
    | 84.5%   fsck.ext2(27): unaligned access to 0x0004feff at ip=0x000140af
fsck.ext2(27): unaligned access to 0x0004feff at ip=0x000140c3
Not-handled unaligned insn 0x27c11018
Unaligned handler failed, ret = -1
      _______________________________
     < Your System ate a SPARC! Gah! >
      -------------------------------
             \   ^__^
              \  (xx)\_______
                 (__)\       )\/\
                  U  ||----w |
                     ||     ||
fsck.ext2(27): Unaligned data reference
fsck.ext2(27): unaligned access to 0x0004feff at ip=0x000140c3
Not-handled unaligned insn 0x27c11018
Unaligned handler failed, ret = -1
      _______________________________
...
--- 8< 8< ---

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: [parisc-linux] [2.5] next issues ...

[Carlos O'Donell]

> Hi,
> 
> 2.5.47-pa3 up and running I added my vlan interface, ssh'ed to the
> host and *buff*
> 

I noticed that your 'uname -a' says you compiled the kernel with gcc-3.2.
AFAIK we have yet to build a kernel with gcc-3.2 that survives network 
traffic. Perhaps try building the kernel with gcc 3.1 or 3.0? 

Helping track down the gcc-3.2 problem would be a wonderful thing :)

c.

Re: [parisc-linux] [2.5] next issues ...

[John David Anglin]

> I noticed that your 'uname -a' says you compiled the kernel with gcc-3.2.
> AFAIK we have yet to build a kernel with gcc-3.2 that survives network 
> traffic. Perhaps try building the kernel with gcc 3.1 or 3.0? 

3.1.1 and 3.2 are identical except for a change in C++ abi, so as far
as kernel building goes they should be the same.  3.3 has a small struct
ABI fix (affects passing of 5-7 byte structs by value), improved long calls
and a workaround for a linker bug affecting PA 2.0 float loads.  If I
was picking, I would go with the current mainline 3.3 or the debian 3.0.

My impression from what Joel has said is that the problem is bad coding
rather than an actual gcc problem.  However, up to now, nobody has been
able to provide a precise analysis of what's going on.

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

Re: [parisc-linux] [2.5] next issues ...

[Randolph Chung]

In reference to a message from John David Anglin, dated Nov 15:
> > I noticed that your 'uname -a' says you compiled the kernel with gcc-3.2.
> > AFAIK we have yet to build a kernel with gcc-3.2 that survives network 
> > traffic. Perhaps try building the kernel with gcc 3.1 or 3.0? 
> 
> 3.1.1 and 3.2 are identical except for a change in C++ abi, so as far
> as kernel building goes they should be the same.  3.3 has a small struct
> ABI fix (affects passing of 5-7 byte structs by value), improved long calls
> and a workaround for a linker bug affecting PA 2.0 float loads.  If I
> was picking, I would go with the current mainline 3.3 or the debian 3.0.
> 
> My impression from what Joel has said is that the problem is bad coding
> rather than an actual gcc problem.  However, up to now, nobody has been
> able to provide a precise analysis of what's going on.

or even duplicate the problem.. i've been building 2.4 and 2.5 kernels
with 3.2 for some time.... haven't seen the problems that have been
reported.

randolph

Re: [parisc-linux] [2.5] next issues ...

[Carlos O'Donell]

> > My impression from what Joel has said is that the problem is bad coding
> > rather than an actual gcc problem.  However, up to now, nobody has been
> > able to provide a precise analysis of what's going on.
> 
> or even duplicate the problem.. i've been building 2.4 and 2.5 kernels
> with 3.2 for some time.... haven't seen the problems that have been
> reported.
> 

32 or 64-bit kernels? All debian tools? Mix of debian and upstream?

My only run-in with the problem was with 32-bit kernels cross compiled
from x86. Though lately I'm using a gcc-3.1 based XC and it builds functional
64-bit kernels.

This is definately becoming one of those HPPA urban legends. I shall add
it to my TODO list and verify that I can build a 32/64-bit kernel
natively and cross with all the latest upstream cvs bits.

c.

Re: [parisc-linux] [2.5] next issues ...

[jsoe0708]

Hey Carlos,

>
>> > My impression from what Joel has said is that the problem is bad coding
>> > rather than an actual gcc problem.  However, up to now, nobody has been
>> > able to provide a precise analysis of what's going on.
>> 
>> or even duplicate the problem.. i've been building 2.4 and 2.5 kernels
>> with 3.2 for some time.... haven't seen the problems that have been
>> reported.
>> 
>
>32 or 64-bit kernels? All debian tools? Mix of debian and upstream?
>

For my part I only tested 32bits 2.4.19 with gcc-3.2 (and previously 3.1).
The same problem occured as well with a cross compiled (hppa->hppa) as native
compiled gcc (following toolchain-howto method).
Unfortunaltely the best I could back trace was that the last kernel function
call was (trivial) dump_stack

>My only run-in with the problem was with 32-bit kernels cross compiled
>from x86. Though lately I'm using a gcc-3.1 based XC and it builds functional
>64-bit kernels.
>
>This is definately becoming one of those HPPA urban legends. I shall add
>it to my TODO list and verify that I can build a 32/64-bit kernel
>natively and cross with all the latest upstream cvs bits.
>

(I did this test _some month ago_ but did not bring me the sol. But that
was some month ago.)

I do also test loopback device (127.0.0.1) but (shame on me) I forgot the
result :((
The goal of this test was to try to point out the location of the problem:
ethernet driver or IP?

Any other idea are well come,
Joel

 

-----------------------------------------------------
ADSL Advantage...L'activation et le 1er mois sont GRATUITS...http://adsl.tiscali.be

Re: [parisc-linux] [2.5] next issues ...

[Bjoern A. Zeeb]

On Fri, 15 Nov 2002, John David Anglin wrote:

> 3.1.1 and 3.2 are identical except for a change in C++ abi, so as far
> as kernel building goes they should be the same.  3.3 has a small struct

ok.

> ABI fix (affects passing of 5-7 byte structs by value), improved long calls
> and a workaround for a linker bug affecting PA 2.0 float loads.  If I

no PA 2.0 here.

> was picking, I would go with the current mainline 3.3 or the debian 3.0.

ok, how and where to get 3.3 from ?
	- subversions.gnu.org cvs ?
	- cvs.parisc-linux.org cvs ? (looks older)

I am going to dig into this.

What about binutils 2.13.90.0.10-2 ... do you know what changes where
there from previous versions ?

Ok, first thing I am going to do is build with gcc 3.0.4 and see if it
works.

all native building btw. here.

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: [parisc-linux] [2.5] next issues ...

[John David Anglin]

> no PA 2.0 here.

If you use a PA 2.0 machine and don't care if your code is compatible
with older machines, then using PA 2.0 code provides a number of
advantages.  Probably, the most important is the change in the maximum
branch distance for pc-relative calls (22-bit vs. 17-bit relocation).
In large programs, it easy to exceed the maximum distance of the 17-bit
relocation.

> > was picking, I would go with the current mainline 3.3 or the debian 3.0.
> 
> ok, how and where to get 3.3 from ?
> 	- subversions.gnu.org cvs ?

This is a mirror of the main gcc source.  I use it except for submissions.

> 	- cvs.parisc-linux.org cvs ? (looks older)
> 
> I am going to dig into this.
> 
> What about binutils 2.13.90.0.10-2 ... do you know what changes where
> there from previous versions ?

I use the main binutils source.  Don't know anything about the debian
changes.  They should be fed back for review if the have any merit.
However, I think Alan Modra did that awhile ago when he was working
on the PA toolchain.

> Ok, first thing I am going to do is build with gcc 3.0.4 and see if it
> works.

Be aware that debian 3.0.4 suffers from a problem where calls that have
a branch distance exceeding the max for a 17-bit relocation are not
correctly changed to an indirect call in all cases.  This will cause a
problem building expr.c in stage1 if you don't include "-O2" in STAGE1_CFLAGS.
This is fixed in 3.1 and latter.  The 3.1/3.2 fix didn't include millicode
calls or PA 2.0 adjustments.  That's now in 3.3.

I'll be glad when debian 3.0.4 is gone.

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

Re: [parisc-linux] [2.5] next issues ...

[Randolph Chung]

> I'll be glad when debian 3.0.4 is gone.

Amen! :-) hopefully we are going to start gcc-3.2 transition fairly
soon.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] [2.5] next issues ...

[John David Anglin]

> Amen! :-) hopefully we are going to start gcc-3.2 transition fairly
> soon.

Don't wait too long!  3.3 may have slipped a bit but the schedule
still shows Dec. 15 2002 as the release date.

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

Re: [parisc-linux] [2.5] next issues ...

[M. Grabert]

On Fri, 15 Nov 2002, John David Anglin wrote:

> > Amen! :-) hopefully we are going to start gcc-3.2 transition fairly
> > soon.
>
> Don't wait too long!  3.3 may have slipped a bit but the schedule
> still shows Dec. 15 2002 as the release date.

I'm not very familiar with the pa-risc internals, but I wonder whether it
is probably a better idea to wait for 3.3?. I've followed the parisc-linux
and the gcc-mailing lists and IMHO gcc-3.3 provides lots of
improvements, not just for Intel, but also for PA-RISC. E.g. a new
scheduler which provides better optimizations (for PA-RISC and lots of
bugfixes are in 3.3. More over the C++ ABI will be changed again, so a
couple  of packages would have to be rebuild AGAIN if we stick to 3.2 (if
not the 3.2-ABI compatibility is used). The people at gcc are just about
to release 3.2.1 and from then they're just focussing on the 3.3-release.
AFAIK they are also to resolve some gcc-hpux/linux issues at the moment,
and I doubt they are going to be in gcc-3.2.1. You probably know much
better than me, but that's just my 2 cent.

I know, it's not the usual debian way (using well tested and very stable
packages), but Linux/PA-RISC is improving/has so much possibilities
to improve, and one major package that contributes to this alot is gcc.


greetings max

PS: I offered to help to track down the problems with Voodoo3 and C240,
but right now I'm really busy (e.g. moving to a new home over the
weekend). Hopefully I'll finnaly have a DSL flatline at home, so I can
work from home ;)

Re: [parisc-linux] [2.5] next issues ...

[Bjoern A. Zeeb]

On Fri, 15 Nov 2002, John David Anglin wrote:

Hi,

> > Ok, first thing I am going to do is build with gcc 3.0.4 and see if it
> > works.
>
> Be aware that debian 3.0.4 suffers from a problem where calls that have
...


had 2.5.47-pa3 compiled with 3.0.4 up ad running
Linux version 2.5.47-pa3 (bz@apollo) (gcc version 3.0.4) #8 Fri Nov 15 23:38:21 UTC 2002

but had trouble with unaligned page access:
--- 8< 8< 8< ---
bz@apollo:~> sshd(315): unaligned access to 0x0006fe7b at ip=0x00020eaf
sshd(315): unaligned access to 0x0006feaf at ip=0x00020eb3
sshd(315): unaligned access to 0x0006feb3 at ip=0x00020eb7
sshd(315): unaligned access to 0x0006feb7 at ip=0x00020ebb
sshd(315): unaligned access to 0x0006febb at ip=0x00020ebf
sshd(315): unaligned access to 0x0006febf at ip=0x00020ec3
sshd(315): unaligned access to 0x0006fec3 at ip=0x00020ec7
sshd(315): unaligned access to 0x0006fec7 at ip=0x00020ecb
sshd(315): unaligned access to 0x0006fecb at ip=0x00020ecf

bz@apollo:~>
bz@apollo:~> dmesg
ommand='sshd' type=6 address=0xed0e6013
vm_start = 0x402b9000, vm_end = 0x402bc000

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111111100001111 Not tainted
r00-03  00000000 fffff000 ed0e6012 59e85014
r04-07  10080302 9d887d40 590cb010 f9080302
r08-11  5ae85014 10080802 42887c40 000e7760
r12-15  00000001 000f7f60 000e7760 000e7760
r16-19  000e7760 00000004 00000004 401dd300
r20-23  0000008e 40166ed4 00000000 00000000
r24-27  000feb50 00000000 00000006 000e7760
r28-31  00000001 00108fe8 0006fe8f 40166ee3
sr0-3   00000000 00000598 00000000 00000598
sr4-7   00000598 00000598 00000598 00000598

IASQ: 00000598 00000598 IAOQ: ed0e6013 ed0e6017
 IIR: 0e760013    ISR: 00000598  IOR: 0006fecb
 CPU:        0   CR30: 151c8000 CR31: 102ac000
 ORIG_R28: 00000000
...
--- 8< 8< 8< ---

Thus it should really be a compiler prob.

So what I did then was ''compiling'' (hopefully) everything with
gcc -S for 3.0.4 and 3.2. Then made a diff between both trees.

For those assembler gurus interested: I placed the bzip2ed diffs at
	http://www.zabbadoz.net/zabbadoz-network/apollo/linux-testing/
in file  gcc-S.diff.bz2 is the wohle diff (without unneccesarry parts)
and file gcc-S-net.diff.bz2 is only linux/net part.
If one really takes a look and needs the whole files, please drop me a
note. I will save them for one or two weeks.


Now I checkout gcc from cvs, updated linux-2.5-pa cvs and compiling...
But it takes ages... and hopefully I will not run out of diskspace
again... let's see what happens...


-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: [parisc-linux] [2.5] next issues ...

[John David Anglin]

> had 2.5.47-pa3 compiled with 3.0.4 up ad running
> Linux version 2.5.47-pa3 (bz@apollo) (gcc version 3.0.4) #8 Fri Nov 15 23:38:21 UTC 2002
> 
> but had trouble with unaligned page access:
> --- 8< 8< 8< ---
> bz@apollo:~> sshd(315): unaligned access to 0x0006fe7b at ip=0x00020eaf
> sshd(315): unaligned access to 0x0006feaf at ip=0x00020eb3

It should be relatively simple to determine what is causing these.
Use objdump or gdb to disassemble the code at the above locations.
The two least-significant bits in the ip addresses should be zeroed
when you do this.

I doubt this is actually a gcc problem but it might be.  I have been
running sshd built with gcc under hpux for years and have built the
latest version with 3.3.  HPUX doesn't have an unaligned trap handler
so the code would just seg fault if the same problem occurred there.

> bz@apollo:~>
> bz@apollo:~> dmesg
> ommand='sshd' type=6 address=0xed0e6013
> vm_start = 0x402b9000, vm_end = 0x402bc000

This is an insn TLB miss fault, so either sshd has branched to
never-never-land or there is a system problem in the management
of the page tables.  In either case, this will be very hard to
debug.  You might get somewhere running sshd under gdb if the
problem is in userland.

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

Re: [parisc-linux] [2.5] next issues ...

[Bjoern A. Zeeb]

On Fri, 15 Nov 2002, John David Anglin wrote:

> was picking, I would go with the current mainline 3.3 or the debian 3.0.

Have you been able to compile a pre3.3 from CVS on parisc ?

regex.c:8214: internal compiler error: Segmentation fault
Please submit a full bug report,

*tralalala*

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: [parisc-linux] [2.5] next issues ...

[John David Anglin]

> On Fri, 15 Nov 2002, John David Anglin wrote:
> 
> > was picking, I would go with the current mainline 3.3 or the debian 3.0.
> 
> Have you been able to compile a pre3.3 from CVS on parisc ?

Yes, many many times.  However, I almost never start from debian 3.0.4.

> regex.c:8214: internal compiler error: Segmentation fault
> Please submit a full bug report,

If this occurred in stage1, the seg fault was in the bootstrap compiler.
Problems with debian 3.0.4 need to be reported on the debian list.
Otherwise, follow the directions for a GCC bug report.

When I saw your report, I started a new bootstrap and it has passed the
point of the above ICE.  Thus, the problem could be in the following
areas:

1) Your bootstrap compiler is broken for one reason or another.  Regex.c
   is a pretty stable bit of code.

2) Your system is unstable.  Various parisc-linux systems have had memory
   management problems causing random segmentation faults.  This has been
   particularly true for SMP configurations.  Sometimes just restarting
   the build will work in this case.

3) There have been problems with bash causing seg faults.  Glibc could
   be involved.

You have to be specific about with compiler version was used for the
bootstrap and the configuration options used for the build.

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

Re: [parisc-linux] [2.5] next issues ...

[Bjoern A. Zeeb]

On Sun, 17 Nov 2002, John David Anglin wrote:

> > regex.c:8214: internal compiler error: Segmentation fault
> > Please submit a full bug report,
>
> When I saw your report, I started a new bootstrap and it has passed the
> point of the above ICE.  Thus, the problem could be in the following

that fast *waeehhh* someone missed that last zero at 715/100(0) 8-(

> areas:
>
> 1) Your bootstrap compiler is broken for one reason or another.  Regex.c
>    is a pretty stable bit of code.

was gcc-3.2; now changed my PATH again and is debian 3.0.4 now in
second run; looks fine so far; takes pretty long for -o java/parse.o
again ...


> 2) Your system is unstable.  Various parisc-linux systems have had memory
>    management problems causing random segmentation faults.  This has been

maybe... have some  ... in dmesg (running 2.4.18-pa33):

do_page_fault() pid=22502 command='conftest' type=15 address=0x40019000
vm_start = 0x40018000, vm_end = 0x40019000

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000011100000000100001111 Not tainted
r00-03  00000000 00021248 000109df 40176300
r04-07  00021386 00021248 0002135e 00000001
r08-11  0002137e 00000000 000d8f68 000f9008
r12-15  00000008 000e8d08 000d8f68 000e95e8
r16-19  00000000 000d24a4 0009e800 00000001
r20-23  40019000 40018000 4005e2fc 00000008
r24-27  0002152c 00000000 00010ff8 00021248
r28-31  00000000 00000219 faf00800 401038e7
sr0-3   00000014 00000014 00000000 00000014
sr4-7   00000014 00000014 00000014 00000014

IASQ: 00000014 00000014 IAOQ: 000109db 00010613
 IIR: 0e931200    ISR: 00000014  IOR: 40019000
 CPU:        0   CR30: 13560000 CR31: 103a0000
 ORIG_R28: 00000000


> 3) There have been problems with bash causing seg faults.  Glibc could
>    be involved.

no bash, nowhere, never, not as dflt ! 2> /dev/null ;-))


> You have to be specific about with compiler version was used for the
> bootstrap and the configuration options used for the build.

gcc-3.2  and --enable-nls=no

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: [parisc-linux] [2.5] next issues ...

[John David Anglin]

> that fast *waeehhh* someone missed that last zero at 715/100(0) 8-(

Yes, full bootstrap and check is close to 24 hours on 100MHz machines.

> do_page_fault() pid=22502 command='conftest' type=15 address=0x40019000
> vm_start = 0x40018000, vm_end = 0x40019000

Faults involving conftest are probably ok.

> no bash, nowhere, never, not as dflt ! 2> /dev/null ;-))

What's /bin/sh?

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

Re: [parisc-linux] [2.5] next issues ...

[Bjoern A. Zeeb]

On Sun, 17 Nov 2002, John David Anglin wrote:

> > that fast *waeehhh* someone missed that last zero at 715/100(0) 8-(
>
> Yes, full bootstrap and check is close to 24 hours on 100MHz machines.

*grmml* failed again in; this time in parse.o

running
../gcc/configure --enable-nls=no --with-gnu-ld \
	--enable-languages=c,c++,objc --disable-libgcj
now

failed too this night...

running

../gcc/configure -v --enable-languages=c,c++,f77,objc --prefix=/usr --infodir=/share/info \
        --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib \
        --enable-long-long --enable-nls --without-included-gettext --disable-checking \
        --enable-threads=posix --with-cpp-install-dir=bin --enable-objc-gc hppa-linux

now. really lokks better ... *grmml*


> > no bash, nowhere, never, not as dflt ! 2> /dev/null ;-))

meant:

bz@apollo:~> echo $SHELL
/usr/bin/tcsh

> What's /bin/sh?

a symlink ;-)  could be (a|k|z|...)sh too but is a bash at the moment...

*_will_* be a sh(1) some day but it's not yet stable and fully usable...

bz@apollo:~/sh> uname
Linux
bz@apollo:~/sh> ./sh -c 'echo BSD rulez \:-\)'
BSD rulez :-)

bz@apollo:~/sh> strings ./sh | egrep -E '(BSD|Berkeley)'
$FreeBSD: src/bin/sh/arith.y,v 1.13 2002/02/02 06:50:45 imp Exp $
$FreeBSD: src/bin/sh/arith_lex.l,v 1.17 2002/02/02 06:50:46 imp Exp $
$FreeBSD: src/usr.bin/printf/printf.c,v 1.26 2002/09/04 23:29:05 dwmalone Exp $
@(#)yaccpar     1.9 (Berkeley) 02/21/93
@(#)history.c   8.1 (Berkeley) 6/4/93
@(#)tokenizer.c 8.1 (Berkeley) 6/4/93

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: [parisc-linux] [2.5] next issues ...

[John David Anglin]

> *grmml* failed again in; this time in parse.o

If the failure was caused by a segmentation fault, restart the build with
"make bootstrap2" or "make bootstrap3" depending on the stage in which
it failed and see what happens.

> ../gcc/configure -v --enable-languages=c,c++,f77,objc --prefix=/usr --infodir=/share/info \

It is not a good idea to replace the default compiler used for building
the system and glibc.  These pretty much have to be kept in sync.  Set
--prefix to some other directory.  It is not a bad idea to keep each
version of gcc in its own directory.  If there is a bug in the installed
compiler, it makes it much easier to do a new build.

The Makefile's use /bin/sh and pretty much assume bash or ksh.

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

Re: [parisc-linux] [2.5] next issues ...

[Bjoern A. Zeeb]

On Mon, 18 Nov 2002, John David Anglin wrote:

> > *grmml* failed again in; this time in parse.o
>
> If the failure was caused by a segmentation fault, restart the build with
> "make bootstrap2" or "make bootstrap3" depending on the stage in which
> it failed and see what happens.

rm -rf'ed the build due to almost no free disk space...

> > ../gcc/configure -v --enable-languages=c,c++,f77,objc --prefix=/usr --infodir=/share/info \
>
> It is not a good idea to replace the default compiler used for building
> the system and glibc.  These pretty much have to be kept in sync.  Set
> --prefix to some other directory.  It is not a bad idea to keep each

*merde* missed it.. copied options from 3.0.4debian /usr/bin/gcc -v

if it compiles it will be no prob to wait another day ;-))

updated my compile.sh ... thanks.

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: [parisc-linux] [2.5] next issues ...

[John David Anglin]

> rm -rf'ed the build due to almost no free disk space...

Use "make bootstrap-lean" to conserve disk space.  This will delete
previous stages when they are no longer needed.

> *merde* missed it.. copied options from 3.0.4debian /usr/bin/gcc -v

You don't need all the options that they use.  Take a look at

http://gcc.gnu.org/ml/gcc-testresults/2002-11/msg00475.html

to the configure options that I use.

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