[parisc-linux] Troubles following the 'recipe'

[parisc-linux] Troubles following the 'recipe'

[Brian Poole]

Hello,

I was looking to test Linux out and see how it was going towards
supporting my poor old HP9000 715/80 that I have here, however I seem to
have some trouble compiling the toolchain as described in the 'recipe' and
would like to ask for some assistance if possible.

I have followed the instructions very closely, deviating only twice in
areas which I can't see affecting my problem. The first was to add -j 2
to the make commands to help speed it up on my systems, as both are SMP.
The other was to grab nfsroot-latest.tar.gz instead of 
nfsroot-20000214.tar.gz, mainly becuase that file no longer exists (might
need to update the recipe?). However as I hadn't reached anything to do
with the nfsroot yet, I deem this inconsquential as well.

So what is the problem? Well, a while (hard to say exactly, one is a
dual 500, the other is a dual 100, big difference in times ;) into the
building of gcc both of my machines error out, complaining that they can't
find some header files. Specifically it errors out while compiling
iogetline.c, complaining that it can't find errno.h (from
../../../gcc/libio/libioP.h:30:19), _G_config.h 
(../../../gcc/libio/libio.h:30:23) and string.h 
(../../../gcc/libio/iogetline.c:27:20). The errors are the same for each
machine. I downloaded all of the files today, October 13th.

Hopefully I am just doing something obviously wrong that someone could
point out to me and I can proceed happily along. Both systems have
working compilers & libraries, one is a SuSE 6.3 install and the other is
Slackware 7.1. I can provide tons more information if it is desired, tried
to just give the information that looked relevant. Or if this is a
waste of time and I should just stop trying to compile my own and grab the
binaries (which I just noticed were also available) please tell me.


Thanks for the time,

-b

Re: [parisc-linux] Troubles following the 'recipe'

[Alan Modra]

On Sat, 14 Oct 2000, Brian Poole wrote:

> find some header files. Specifically it errors out while compiling
> iogetline.c, complaining that it can't find errno.h (from
> ../../../gcc/libio/libioP.h:30:19), _G_config.h 
> (../../../gcc/libio/libio.h:30:23) and string.h 
> (../../../gcc/libio/iogetline.c:27:20). The errors are the same for each
> machine. I downloaded all of the files today, October 13th.

Can you show the command line that failed here?  If you followed the
recipe, then you should have configured gcc with --prefix=$DEST, and have 
$DEST/include/errno.h on your system.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Troubles following the 'recipe'

[Brian Poole]

> Alan Modra wrote..
> Can you show the command line that failed here? If you followed the

Sure. The exact command that this output came from was..

make -j2 LIBGCC2_INCLUDES=-I$DEST/include

And I configured it as per the recipe with..

../gcc/configure --target=hppa1.1-linux --prefix=$DEST --host=$MACH
--disable-nls --without-libc

which according to configure configured gcc as..

../gcc/configure
--with-gcc-version-trigger=/home/raj/parisc/gcc/gcc/version.c
--target=hppa1.1-linux --prefix=/usr/parisc --host=i386-linux
--disable-nls --without-libc --norecursion

> recipe, then you should have configured gcc with --prefix=$DEST, and have 
> $DEST/include/errno.h on your system.

Indeed, I noted this myself, was wondering why it had not found headers
that I should have. The errno.h header is in fact in $DEST/include,
checked then and just checked again.

However doesn't prefix indicate where it is installing to, and not where
it is reading from for it's includes, or am I missing something? 


Thanks for the help,

-b

Re: [parisc-linux] Troubles following the 'recipe'

[David Huggins-Daines]

Brian Poole <raj@cerias.purdue.edu> writes:

> And I configured it as per the recipe with..
> 
> ../gcc/configure --target=hppa1.1-linux --prefix=$DEST --host=$MACH
> --disable-nls --without-libc

--without-libc does nothing.  You also need --enable-languages=c, or
else it will try to build ObjC, C++, Java, etc., all of which require
you to have a built libc.

Another thing - though 'hppa1.1-linux' works, you should use
'hppa-linux' as the target instead.

You should configure gcc with:

../gcc/configure --target=hppa-linux --prefix=$DEST --enable-languages=c

If you want a cross-compiler for C++, you must build a cross-glibc
(using --prefix=$DEST/hppa-linux - important!) and then rebuild with
--enable-languages=c,c++.

I thought the recipe had been updated (I *clearly* remember helping
write a functional one a while ago).  Are you sure this is a recent
version of it?

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] Troubles following the 'recipe'

[Brian Poole]

On 14 Oct 2000, David Huggins-Daines wrote:

> Brian Poole <raj@cerias.purdue.edu> writes:
> 
> > And I configured it as per the recipe with..
> > 
> > ../gcc/configure --target=hppa1.1-linux --prefix=$DEST --host=$MACH
> > --disable-nls --without-libc
> 
> --without-libc does nothing.  You also need --enable-languages=c, or
> else it will try to build ObjC, C++, Java, etc., all of which require
> you to have a built libc.
> 
> Another thing - though 'hppa1.1-linux' works, you should use
> 'hppa-linux' as the target instead.
> 
> You should configure gcc with:
> 
> ../gcc/configure --target=hppa-linux --prefix=$DEST --enable-languages=c
> 
> If you want a cross-compiler for C++, you must build a cross-glibc
> (using --prefix=$DEST/hppa-linux - important!) and then rebuild with
> --enable-languages=c,c++.
> 
> I thought the recipe had been updated (I *clearly* remember helping
> write a functional one a while ago).  Are you sure this is a recent
> version of it?

This is off of http://thepuffingroup.com/parisc/recipe.html which says
page was last modified 09/30/2000. Guess this puppy is a bit out of date
despite what the page says because everything I've been doing is off that 
one. I noticed it building the Java, etc, but assumed that was just the
way things were supposed to go. Any idea what you did with that functional
one? ;)

I'll try recompiling with the above stated configure and see if I get any
better luck. 


thanks,

-b

Re: [parisc-linux] Troubles following the 'recipe'

[Alan Modra]

On Sat, 14 Oct 2000, Brian Poole wrote:

> On 14 Oct 2000, David Huggins-Daines wrote:
> > Another thing - though 'hppa1.1-linux' works, you should use
> > 'hppa-linux' as the target instead.

The only thing this affects is later compiles of eg. the kernel, which
have Makefiles set up to expect a cross-compiler called hppa-linux-gcc

> > You should configure gcc with:
> > 
> > ../gcc/configure --target=hppa-linux --prefix=$DEST --enable-languages=c
> > 
> > If you want a cross-compiler for C++, you must build a cross-glibc
> > (using --prefix=$DEST/hppa-linux - important!) and then rebuild with
> > --enable-languages=c,c++.
> > 
> > I thought the recipe had been updated (I *clearly* remember helping
> > write a functional one a while ago).  Are you sure this is a recent
> > version of it?
> 
> This is off of http://thepuffingroup.com/parisc/recipe.html which says
> page was last modified 09/30/2000. Guess this puppy is a bit out of date
> despite what the page says because everything I've been doing is off that 
> one. I noticed it building the Java, etc, but assumed that was just the
> way things were supposed to go. Any idea what you did with that functional
> one? ;)
> 
> I'll try recompiling with the above stated configure and see if I get any
> better luck. 

Bung your includes into ${DEST}/${TARGET}/include, as that is the 
directory where a cross-compiler expects to find them (as you
found from the gcc -v).  That's the real fix to your problem.  Sorry I
didn't think of it earlier.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Troubles following the 'recipe'

[Brian Poole]

On Sun, 15 Oct 2000, Alan Modra wrote:
> 
> Bung your includes into ${DEST}/${TARGET}/include, as that is the 
> directory where a cross-compiler expects to find them (as you
> found from the gcc -v).  That's the real fix to your problem.  Sorry I
> didn't think of it earlier.
> 
Hmm.. seems to be never ending problems here.. I made all recommended
changes and now the compile of gcc errors out with compilation errors..

specifically in gcc.c (beginning path is cut off to save my fingers)
gcc.c: In function `execute':
gcc.c:2559: `prus' has incomplete type
gcc.c:2560: `RUSAGE_CHILDREN' undeclared (first use in this function)
(warns that each undeclared is only warned about once)
gcc.c:2561: invalid use of undefined type `struct rusage'
(repeats ~10 times, diff line numbers)
gcc.c: At top level:
gcc.c:204: storage size of `rus' isn't known
gcc.c:204: storage size of `prus isn't known
make[1]: *** [gcc.o] Error 1
make[1]: Leaving directory `/d0/parisc-build/gcc-build/gcc'

sighs.. maybe I'll just leave parisc linux alone for a few months again
and see how it is doing again later ;)


-b

Re: [parisc-linux] Troubles following the 'recipe'

[Alan Modra]

On Sat, 14 Oct 2000, Brian Poole wrote:

> Hmm.. seems to be never ending problems here.. I made all recommended
> changes and now the compile of gcc errors out with compilation errors..
> 
> specifically in gcc.c (beginning path is cut off to save my fingers)

I'm not sure what this one is due to, but since it's during the compile of
gcc itself rather than gcc libraries, then it's likely something to do
with the include setup on your system.  ie. This problem likely isn't
anything to do with parisc gcc.  I suspect you will have problems
compiling other programs too.  Do you have a links /usr/include/linux and
/usr/include/asm pointing to kernel includes?  ie. something like the
following:

$ ls -l /usr/include/{linux,asm}
lrwxrwxrwx   1 root     root           24 Oct 25  1999 /usr/include/asm ->
../src/linux/include/asm
lrwxrwxrwx   1 root     root           26 Oct 25  1999 /usr/include/linux
-> ../src/linux/include/linux

$ grep rusage /usr/include/linux/*
/usr/include/linux/resource.h: * Definition of struct rusage taken from
BSD 4.3 Reno
/usr/include/linux/resource.h:struct    rusage {

> gcc.c: In function `execute':
> gcc.c:2559: `prus' has incomplete type
> gcc.c:2560: `RUSAGE_CHILDREN' undeclared (first use in this function)
> (warns that each undeclared is only warned about once)
> gcc.c:2561: invalid use of undefined type `struct rusage'
> (repeats ~10 times, diff line numbers)
> gcc.c: At top level:
> gcc.c:204: storage size of `rus' isn't known
> gcc.c:204: storage size of `prus isn't known
> make[1]: *** [gcc.o] Error 1
> make[1]: Leaving directory `/d0/parisc-build/gcc-build/gcc'

--
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Troubles following the 'recipe'

[John David Anglin]

> So what is the problem? Well, a while (hard to say exactly, one is a
> dual 500, the other is a dual 100, big difference in times ;) into the
> building of gcc both of my machines error out, complaining that they can't
> find some header files. Specifically it errors out while compiling
> iogetline.c, complaining that it can't find errno.h (from
> ../../../gcc/libio/libioP.h:30:19), _G_config.h 
> (../../../gcc/libio/libio.h:30:23) and string.h 
> (../../../gcc/libio/iogetline.c:27:20). The errors are the same for each
> machine. I downloaded all of the files today, October 13th.

Run the failing compilation with the gcc `-v' option to see the include search
directories.

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

Re: [parisc-linux] Troubles following the 'recipe'

[Brian Poole]

On Sat, 14 Oct 2000, John David Anglin wrote:
> 
> Run the failing compilation with the gcc `-v' option to see the include search
> directories.
> 

Ah this seems to yield a bit more light..

It ignores about 8 non-existent dirs.. 
(I've added BDIR=/home/raj/parisc/gcc-build to help shorten my typing.. no
mouse. DEST is still /usr/parisc :)

$DEST/hppa1.1-linux/bin/include
$DEST/hppa1.1-linux/lib/include
$DEST/hppa1.1-linux/include
$BDIR/lib/gcc-lib/hppa1.1-linux/2.96/include
$BDIR/hppa1.1-linux/sys-include
$BDIR/hppa1.1-linux/include
$DEST/hppa1.1-linux/sys-include
$DEST/hppa1.1-linux/include

then outputs..

#include "..." search starts here:
#include <...> search starts here:
 .
 ../../../gcc/libio
 $BDIR/gcc/include
 $DEST/lib/gcc-lib/hppa1.1-linux/2.96/include

Well now, it doesn't seem to be reading $DEST/include, why is it not?
Seems strange that I be the only one to encounter this problem, given
the same set of simple instructions. As well, how do I fix this? 

In the Makefile under gcc-build it lists the includedir=${prefix}/include
and prefix as /usr/parisc, which looks correct.. ideas?

Thanks again,

-b

Re: [parisc-linux] Troubles following the 'recipe'

[John David Anglin]

> Ah this seems to yield a bit more light..
> 
> It ignores about 8 non-existent dirs.. 
> (I've added BDIR=/home/raj/parisc/gcc-build to help shorten my typing.. no
> mouse. DEST is still /usr/parisc :)
> 
> $DEST/hppa1.1-linux/bin/include
> $DEST/hppa1.1-linux/lib/include
> $DEST/hppa1.1-linux/include
> $BDIR/lib/gcc-lib/hppa1.1-linux/2.96/include
> $BDIR/hppa1.1-linux/sys-include
> $BDIR/hppa1.1-linux/include
> $DEST/hppa1.1-linux/sys-include
> $DEST/hppa1.1-linux/include
> 
> then outputs..
> 
> #include "..." search starts here:
> #include <...> search starts here:
>  .
>  ../../../gcc/libio
>  $BDIR/gcc/include
>  $DEST/lib/gcc-lib/hppa1.1-linux/2.96/include
> 
> Well now, it doesn't seem to be reading $DEST/include, why is it not?
> Seems strange that I be the only one to encounter this problem, given
> the same set of simple instructions. As well, how do I fix this? 
> 
> In the Makefile under gcc-build it lists the includedir=${prefix}/include
> and prefix as /usr/parisc, which looks correct.. ideas?

Did you install gcc?  The include paths are a bit different if it isn't
installed.

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

Re: [parisc-linux] Troubles following the 'recipe'

[Grant Grundler]

Brian Poole wrote:
> Hello,
> 
> I was looking to test Linux out and see how it was going towards
> supporting my poor old HP9000 715/80 that I have here, however I seem to
> have some trouble compiling the toolchain as described in the 'recipe' and
> would like to ask for some assistance if possible.

The recipe is definitely out of date.
It's been on the TODO list since last week.
It would be great if Alan Modra updated it.

You can look at build-tools/recipe.linux or other files in build-tools
CVS repository at:
	http://puffin.external.hp.com/cgi-bin/cvsview/build-tools/


enjoy,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] Troubles following the 'recipe'

[Alan Modra]

On Sun, 15 Oct 2000, Grant Grundler wrote:

> The recipe is definitely out of date.
> It's been on the TODO list since last week.
> It would be great if Alan Modra updated it.

Sorry, I've been a bit slow.  Also did a surprising number of things the
wrong way first time when building everything from scratch.  :-(
Rebuilding from a working tool-base is quite different from starting over.

Anyway, what's there now Works For Me.  (I hope there's not too many
typos)  At least, it would be on the web site if I knew how to go about
pushing stuff from puffin.external.hp.com to www.thepuffingroup.com  Ain't
got no keys to open the door, Ma.

Currently the doco is available at
ftp://puffin.external.hp.com/pub/parisc/debug/recipe.x

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Troubles following the 'recipe'

[Bruno Vidal]

	Hi
I try to completly rebuild chaintool with the last recipe. It works much more
better than the last time I try to build it. I still have some trouble with building
glibc with includes (but it's okay, I'm able to correct it). The compilation is okay,
but in the make install:
.././scripts/install-sh -c /opt/linux_hppa/src/build/glibc/elf/ld.so /opt/linux/hppa-linux/lib/ld-2.1.92.so.new
mv -f /opt/linux/hppa-linux/lib/ld-2.1.92.so.new /opt/linux/hppa-linux/lib/ld-2.1.92.so
make[2]: *** No rule to make target `/opt/linux/hppa-linux/lib/libc-2.1.92.so', needed by `/opt/linux/hppa-linux/lib/ld.so.1'.  Stop.
 
I'm not very proficient with makefiles, and I'm not able to debug this one.
The libc has been correctly build:
#ll /opt/linux_hppa/src/build/glibc/libc.so
-rwxr-xr-x   1 root       sys        4465666 Oct 17 10:05 /opt/linux_hppa/src/build/glibc/libc.so
#file /opt/linux_hppa/src/build/glibc/libc.so
/opt/linux_hppa/src/build/glibc/libc.so:        ELF-32 shared object file - PA-RISC 
#strings /opt/linux_hppa/src/build/glibc/libc.so | grep 2.1.92
2.1.92
GNU C Library development release version 2.1.92, by Roland McGrath et al.

And "ld" looks good to, and have been succesfully installed just before this error.


So, all looks okay, but makefile for install stuff seems to be wrong.
Do you have any clue ?

	Thanks.
-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

Re: [parisc-linux] Troubles following the 'recipe'

[Alan Modra]

On Tue, 17 Oct 2000, Bruno Vidal wrote:

> but in the make install:
> .././scripts/install-sh -c /opt/linux_hppa/src/build/glibc/elf/ld.so /opt/linux/hppa-linux/lib/ld-2.1.92.so.new
> mv -f /opt/linux/hppa-linux/lib/ld-2.1.92.so.new /opt/linux/hppa-linux/lib/ld-2.1.92.so
> make[2]: *** No rule to make target `/opt/linux/hppa-linux/lib/libc-2.1.92.so', needed by `/opt/linux/hppa-linux/lib/ld.so.1'.  Stop.

Immediately after installing ld.so, "make install" should be installing
the new libc.so.  Hmm, your glibc sources are not the latest puffin ones,
as the latest glibc will install as 2.1.94  You might have better luck
after updating (via cvs).  At some point glibc configure was changed to
require make-3.79.1 or later to compile glibc, perhaps in response to a
problem such as you are seeing, so maybe you also need to upgrade "make".

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Troubles following the 'recipe'

[David Huggins-Daines]

Alan Modra <alan@linuxcare.com.au> writes:

> Immediately after installing ld.so, "make install" should be installing
> the new libc.so.  Hmm, your glibc sources are not the latest puffin ones,
> as the latest glibc will install as 2.1.94 

2.1.95 actually.  (Sorry for not announcing this on the list)

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

[parisc-linux] Troubles with read only file system

[Thomas Marteau]

Hi all,

We have done everything well but the NFSroot and the bootable disk say that
we have a read only file system ???
What is the recipe for making a bootable disk because ours can not be the
good one...

Thanks,

Thomas

Re: [parisc-linux] Troubles with read only file system

[Grant Grundler]

"Thomas Marteau" wrote:
> Hi all,
> 
> We have done everything well but the NFSroot and the bootable disk say that
> we have a read only file system ???

Yeah...RO the default behavior.
I have the following entry on my NFS root etc/fstab:

15.8.81.247:/tftpboot/hppa / nfs defaults                       0       0

You can also manually:
	mount -o remount,rw /

This should work for both NFS root and SCSI root disks.

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

[parisc-linux] /proc/interrupts

[Helge Deller]

Hi all,

I just committed changes, which fills in i386-compatible 
interrupt-information into /proc/interrupts.

During the changes I inserted the constants IRQ_PER_REGION and 
IRQ_REGION_SHIFT into asm-parisc/irq.h, which would allow us to reduce the 
needed amount of static memory for the interrupt routing tables.

This change has following effects:
1. The until now used virtual IRQ's gets new numbers and increments in every 
region by 32 for parisc32 and 64 for parisc64. The old IRQ regions 
incremented by 256.
2. since we now shift by values of 5 (parisc32) or 6 (parisc64) bits, the 
time needed to calculate the offsets may have changed. This needs to be 
inspected.
3. the new algorithm needs less memory than before.

By default I left the current behaviour in CVS, but you may activate the new 
algorithm by changing the "#if 0" to "#if 1" in asm-parsic/irq.h and tell me 
what you think.

Thanks,
Helge.

Re: [parisc-linux] /proc/interrupts

[Grant Grundler]

Hi Helge!

Helge Deller wrote:
...
> 1. The until now used virtual IRQ's gets new numbers and increments in every 
> region by 32 for parisc32 and 64 for parisc64. The old IRQ regions 
> incremented by 256.

prumpf did something like this too.
It's better - but IMHO not "optimal".

I've been thinking about an "optimal" solution but haven't had a chance
to try it out. Here's my proposal:
o "invent" (yeah...I heard you, Carly! :^) a global "action" table.
o All IRQ allocation will get an "action" entry from the global table.
o And each IRQ region is a table of "action" pointers.
o "busy" IRQ region entries point to entries in the global "action" table.

"action" is a IRQ handler + arguments stuffed in a data structure.

Here are some examples of why I think this is "optimal":
o Older Workstations typically only need 10-20 "action" entries in
  2-4 IRQ regions.
o A500/C3000/J5000/L2000 might need about the same number of "action"
  entries but spread over 8 IRQ regions (4 CPU + 4 I/O Sapic).
o N-4000 might use over 60 entries in 22 IRQ regions!
  (12*4+8+5) That's 12 PCI Slots, 8 CPUs, and 5 built-in PCI devices
  spread over 8 CPU + 14 I/O Sapic.
o I don't know the limits of Superdome which was just announced.
  I've been asked about running linux on Superdome and my reply is
  first get it running on N-class (which isn't currently "in-plan"
  officially).

(Note: Even though today we only allocate one IRQ region for all CPUs,
in the future I'd like to see each CPU get it's own region.)

> 2. since we now shift by values of 5 (parisc32) or 6 (parisc64) bits, the 
> time needed to calculate the offsets may have changed. This needs to be 
> inspected.

I don't think this will be an issue.
I doubt a shift op takes longer (as measured in cycles) to shift more/less.


> 3. the new algorithm needs less memory than before.

yup - hypothetically by 4x or 8x. That's a good thing.

> By default I left the current behaviour in CVS, but you may activate the new 
> algorithm by changing the "#if 0" to "#if 1" in asm-parsic/irq.h and tell me 
> what you think.

That's cool...I'll enable it here for testing.
Remember - no news is good news :^)

thanks!
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253