[parisc-linux] Building from scratch.

[parisc-linux] Building from scratch.

[Carlos O'Donell Jr.]

Parisc'ers,

I was recently trying to build the toolchain from scractch on
an x86 box.

I've run into the following stumbling block:

a) glibc configure requires that I use "--enable-hacker-mode"

This really isn't documented, but It's not uncommon and I got around
it very quickly ;)

The second issue was:

b) Some strange asm problem while building glibc.

gcc ../sysdeps/unix/sysv/linux/hppa/sysdep.c -c -O2 -Wall -Winline -Wstrict=
-prototypes -Wwrite-strings -g      -I../include -I. -I/mnt/fatty/palinux/b=
uild/glibc/csu -I.. -I../libio  -I/mnt/fatty/palinux/build/glibc -I../sysde=
ps/hppa/elf -I../linuxthreads/sysdeps/unix/sysv/linux/hppa -I../linuxthread=
s/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthrea=
ds/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysde=
ps/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/u=
nix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../s=
ysdeps/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/f=
pu -I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sys=
deps/generic   -D_LIBC_REENTRANT -include ../include/libc-symbols.h     -DH=
AVE_INITFINI -o /mnt/fatty/palinux/build/glibc/csu/sysdep.o
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c: In function `syscall':
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c:43: invalid register name `r28' =
for register variable
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c:44: invalid register name `r21' =
for register variable
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c:44: invalid register name `r22' =
for register variable
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c:44: invalid register name `r23' =
for register variable
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c:44: invalid register name `r24' =
for register variable
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c:44: invalid register name `r25' =
for register variable
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c:44: invalid register name `r26' =
for register variable
=2E./sysdeps/unix/sysv/linux/hppa/sysdep.c:45: Can't find a register in cla=
ss `GENERAL_REGS' while reloading `asm'.
make[2]: *** [/mnt/fatty/palinux/build/glibc/csu/sysdep.o] Error 1
make[2]: Leaving directory `/mnt/fatty/palinux/src/glibc/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/mnt/fatty/palinux/src/glibc'
make: *** [all] Error 2


Background:

I started by building the tools, as per the instructions on the website.

- Built binutils
- Partially build gcc
- Unpack and configure kernel
- Build glibc...

At which I'm stuck. My hppa bin directory has the following built tools:
(and is on my path)

gccbug                hppa-linux-cpp      hppa-linux-objdump
gcov                  hppa-linux-gasp     hppa-linux-ranlib
hppa-linux-addr2line  hppa-linux-gcc      hppa-linux-readelf
hppa-linux-ar         hppa-linux-ld       hppa-linux-size
hppa-linux-as         hppa-linux-nm       hppa-linux-strings
hppa-linux-c++filt    hppa-linux-objcopy  hppa-linux-strip

The configure for glibc does complain about:

[snip]
checking for hppa-linux-mig... (cached) mig
configure: warning:=20
*** An auxiliary program is missing or too old;
*** some features will be disabled.
*** Check the INSTALL file for required versions.
checking whether ranlib is necessary... (cached) no
[snip]

But continues on. I've met all the requirements in INSTALL, with=20
regards to tools and their versions.

Any clues?

Cheers,
Carlos.

Re: [parisc-linux] Building from scratch.

[Matthew Wilcox]

On Sun, Aug 26, 2001 at 04:27:54PM -0400, Carlos O'Donell Jr. wrote:
> I started by building the tools, as per the instructions on the website.
> 
> - Built binutils
> - Partially build gcc
> - Unpack and configure kernel
> - Build glibc...

Where did you get glibc from?  The only place with current patches is the
Debian package.  Our CVS is terribly out of date.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Building from scratch.

[Carlos O'Donell Jr.]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

> > I started by building the tools, as per the instructions on the website.
> > 
> > - Built binutils
> > - Partially build gcc
> > - Unpack and configure kernel
> > - Build glibc...
> 
> Where did you get glibc from?  The only place with current patches is the
> Debian package.  Our CVS is terribly out of date.
> 
> -- 
> Revolutions do not require corporate support.

M,

That explains things...

ftp://puffin.external.hp.com/pub/parisc/cvs <== Bad!

ftp://ftp.debian.org/debian/pool/main/g/glibc/ <== Good!?

Cheers,
Carlos.

p.s. Small diff to the toolchain index.html ?

[-- Attachment #2: index.html.diff --]
[-- Type: text/plain, Size: 1607 bytes --]

--- ./toolchain/index.html	Mon Aug 27 22:45:01 2001
+++ index.html	Mon Aug 27 23:47:33 2001
@@ -94,9 +94,23 @@
 <br>&nbsp;<br>
 The source trees of all of these are available through <A HREF="../tools/index.html">CVS</A> but we also make available nightly snapshots from <A HREF="ftp://puffin.external.hp.com/pub/parisc/cvs/">here</A>.  It is best to get a snapshot the first time you want to build a tree and update from CVS from then on. <BR>
 
-
 <OL>
 <strong><LI>Fetch GCC, Binutils, Glibc, Linux:</strong>
+<br>&nbsp;<BR>
+Note that the /pub/parisc/cvs snapshots may not be completely up
+to date for glibc. The most complete snapshots may be found at the debian
+pool <a href="ftp://ftp.debian.org/debian/pool/main">ftp://ftp.debian.org/debian/pool/main</a>. Although the example lists glibc 2.2.4, you will want to replace this with the latest available glibc version.
+<PRE>
+cd
+mkdir source
+mkdir build
+cd source
+wget ftp://ftp.debian.org/debian/pool/main/g/glibc/glibc_2.2.4.orig.tar.gz
+wget ftp://puffin.external.hp.com/pub/parisc/cvs/binutils-latest.tar.gz
+wget ftp://puffin.external.hp.com/pub/parisc/cvs/gcc-latest.tar.gz
+wget ftp://puffin.external.hp.com/pub/parisc/cvs/linux-latest.tar.gz
+</PRE>
+Or alternatively:
 <PRE>
 cd
 mkdir source
@@ -109,9 +123,15 @@
 get binutils-latest.tar.gz
 get gcc-latest.tar.gz
 get linux-latest.tar.gz
-get glibc-latest.tar.gz
+quit
+ftp ftp.debian.org
+user: anonymous
+password: you@your.email.address
+cd debian/pool/main/g/glibc
+get glibc_2.2.4.orig.tar.gz
 quit
 </PRE>
+
 
 <strong>Determine the host system setup:</strong>
 <br>&nbsp;<br>

Re: [parisc-linux] Building from scratch.

[Carlos O'Donell Jr.]

> 
> Where did you get glibc from?  The only place with current patches is the
> Debian package.  Our CVS is terribly out of date.
> 
> -- 
> Revolutions do not require corporate support.
> 
>

wget ftp://ftp.debian.org/debian/pool/main/g/glibc/glibc_2.2.4.orig.tar.gz

And applied glibc_2.2.4-1.diff from same directory.

---
make[2]: Leaving directory `/mnt/fatty/palinux/src/glibc/csu'
make[2]: Entering directory `/mnt/fatty/palinux/src/glibc/csu'
gcc ../sysdeps/unix/sysv/linux/hppa/sysdep.c -c -O2 -Wall -Winline -Wstrict-pro
totypes -Wwrite-strings -g      -I../include -I. -I/mnt/fatty/palinux/build/gli
bc/csu -I.. -I../libio  -I/mnt/fatty/palinux/build/glibc -I../sysdeps/hppa/elf 
-I../linuxthreads/sysdeps/unix/sysv/linux/hppa -I../linuxthreads/sysdeps/unix/s
ysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthre
ads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/
hppa -I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdep
s/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/hpp
a1.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   -D_LIBC_REEN
TRANT -include ../include/libc-symbols.h     -DHAVE_INITFINI -o /mnt/fatty/pali
nux/build/glibc/csu/sysdep.o
../sysdeps/unix/sysv/linux/hppa/sysdep.c: In function `syscall':
../sysdeps/unix/sysv/linux/hppa/sysdep.c:45: invalid register name `r28' for re
gister variable
../sysdeps/unix/sysv/linux/hppa/sysdep.c:46: invalid register name `r21' for re
gister variable
../sysdeps/unix/sysv/linux/hppa/sysdep.c:46: invalid register name `r22' for re
gister variable
../sysdeps/unix/sysv/linux/hppa/sysdep.c:46: invalid register name `r23' for re
gister variable
../sysdeps/unix/sysv/linux/hppa/sysdep.c:46: invalid register name `r24' for re
gister variable
../sysdeps/unix/sysv/linux/hppa/sysdep.c:46: invalid register name `r25' for re
gister variable
../sysdeps/unix/sysv/linux/hppa/sysdep.c:46: invalid register name `r26' for re
gister variable
../sysdeps/unix/sysv/linux/hppa/sysdep.c:47: Can't find a register in class `GE
NERAL_REGS' while reloading `asm'.
make[2]: *** [/mnt/fatty/palinux/build/glibc/csu/sysdep.o] Error 1
make[2]: Leaving directory `/mnt/fatty/palinux/src/glibc/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/mnt/fatty/palinux/src/glibc'
make: *** [all] Error 2
---

[carlos@systemhalted hppa]$ ls -alt sysdep.c 
-rw-rw-r--    1 carlos   carlos       1794 Jul 23 13:57 sysdep.c
[carlos@systemhalted hppa]$ 

Any thoughts or helpfull comments? :)
How do you developers do it?

Cheers,
Carlos.

Re: [parisc-linux] Building from scratch.

[Matthew Wilcox]

On Tue, Aug 28, 2001 at 12:39:52AM -0400, Carlos O'Donell Jr. wrote:
> wget ftp://ftp.debian.org/debian/pool/main/g/glibc/glibc_2.2.4.orig.tar.gz
> 
> And applied glibc_2.2.4-1.diff from same directory.

2.2.4-1 doesn't build.  I haven't investigated in any detail, but it gets
further than your build error indicates.  Use dpkg-buildpackage to build
it... and you need to uncomment the hppa-specific patch in 0list... and
you need to edit the patch anyway to get it to apply...

I have no enthusiasm for working on glibc.  Please, someone, take it
off my hands.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Building from scratch.

[Carlos O'Donell Jr.]

> > And applied glibc_2.2.4-1.diff from same directory.
> 
> 2.2.4-1 doesn't build.  I haven't investigated in any detail, but it gets
> further than your build error indicates.  Use dpkg-buildpackage to build
> it... and you need to uncomment the hppa-specific patch in 0list... and
> you need to edit the patch anyway to get it to apply...
> 
> I have no enthusiasm for working on glibc.  Please, someone, take it
> off my hands.
> 
> -- 
> Revolutions do not require corporate support.
>

I have also tried building 2.2.4 without the diff, but with no success.

What would be the responsibilities of said maintianer?

The small fact that "uncomment the hppa-specific patch in 0list" means
little to nothing to me ;) ... is probably an indication that I'm not
experienced enough to take on glibc.

Seeing as you are the current glibc maintainer, my question would be:
What type of process do you follow for maintaining glibc?

a) Kick machine until glibc works.
b) Throw machines out window until glibc works.
c) Wait. Glibc will fix itself.
d) Who nees glibc? PARISC ASM!
e) Stay up many hours extracting those pesky pieces that don't work with HPPA.

Thanks for all the invaluable help Matthew! :}

I promise to try and stop doing crazy things like building the toolchain
by hand ;)

Cheers,
Carlos

Re: [parisc-linux] Building from scratch.

[Matthew Wilcox]

On Tue, Aug 28, 2001 at 07:17:43AM -0400, Carlos O'Donell Jr. wrote:
> I have also tried building 2.2.4 without the diff, but with no success.

No, you definitely need the diff, you just need a little more than that
too :-)

> What would be the responsibilities of said maintianer?

Keeping the diff in the glibc tree up to date, trying to merge it upstream,
fixing bugs as they arise.

> The small fact that "uncomment the hppa-specific patch in 0list" means
> little to nothing to me ;) ... is probably an indication that I'm not
> experienced enough to take on glibc.

Let's see:

apt-get source glibc
cd glibc-2.2.4-1
vi debian/patches/0list
	delete the `#' from the front of glibc22-hppa.

I've fixed some problems with this patch, but it still dies doing the
install.

> Seeing as you are the current glibc maintainer, my question would be:
> What type of process do you follow for maintaining glibc?

Really, I don't.  I have no enthusiasm for working on glibc, so I simply
wait for debian to do new glibc releases and ensure the patch still applies.
The various bits in the patch need to get merged upstream, but I don't
enjoy dealing with drepper, so I haven't been working on that either.

> I promise to try and stop doing crazy things like building the toolchain
> by hand ;)

If you were to take over maintaining glibc, I'd forgive you :-)

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Building from scratch.

[Carlos O'Donell Jr.]

> 
> No, you definitely need the diff, you just need a little more than that
> too :-)
> 

I didn't need much more than that... I ignored the errors generated by
the patch (there were no errors on the critical hppa stuff, just some
touches into the ia64 section? Didn't look into it in much detail)

Boy did I fsck in my pants when I forgot that LD_LIBRARY_PATH had the
current directory ... and I cd'd into the glibc build directory :}

> 
> Keeping the diff in the glibc tree up to date, trying to merge it upstream,
> fixing bugs as they arise.
> 

I've never merged upstream, does it hurt? :}

> 
> Let's see:
> 
> apt-get source glibc
> cd glibc-2.2.4-1
> vi debian/patches/0list
> 	delete the `#' from the front of glibc22-hppa.
> 
> I've fixed some problems with this patch, but it still dies doing the
> install.
> 

Are you using dpkg-buildpackage to build it all?
Not having a debain based system makes it harder to test this...
(I might install all the deb tools and give it a try...)

'make install' worked on my box.

I theoretically have a working glibc 2.2.4-1 created using gcc-latest and
binutils-latest from the parisc ftp-site.

> 
> Really, I don't.  I have no enthusiasm for working on glibc, so I simply
> wait for debian to do new glibc releases and ensure the patch still applies.
> The various bits in the patch need to get merged upstream, but I don't
> enjoy dealing with drepper, so I haven't been working on that either.
> 
> If you were to take over maintaining glibc, I'd forgive you :-)
>

[carlos@systemhalted debian]$ man drepper
No manual entry for drepper
rlos@systemhalted debian]$ apropos ulrich
ulrich: nothing appropriate

Nothing appropriate indeed!
I can't see to find that tool, I'm sure it won't be hard to work with... ;)

I might take over maintaining glibc, but not quite yet...
If you let me get comfortable, possibly introducing me to the methodology
or just letting me shadow what you do... I might just take it from you ;)

Cheers,
Carlos. 

Re: [parisc-linux] Building from scratch.

[Matthew Wilcox]

On Tue, Aug 28, 2001 at 11:29:00AM -0400, Carlos O'Donell Jr. wrote:
> I've never merged upstream, does it hurt? :}

Sometimes... see the archives.

> Are you using dpkg-buildpackage to build it all?

Yes, it takes a tree and builds new .deb files out of it for you.

> Not having a debain based system makes it harder to test this...
> (I might install all the deb tools and give it a try...)

Could help you out later, yep.

> 'make install' worked on my box.
> 
> I theoretically have a working glibc 2.2.4-1 created using gcc-latest and
> binutils-latest from the parisc ftp-site.

Mmm.  I would expect it to not work.  My build dies when it uses part of itself
in the install:

/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/elf/ld.so.1 --library-path 
/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj:/home/willy/glibc/2.2.4-1/g
libc-2.2.4/hppa-linux/obj/math:/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/
obj/elf:/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/dlfcn:/home/willy/g
libc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/nss:/home/willy/glibc/2.2.4-1/glibc-2.2.
4/hppa-linux/obj/nis:/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/rt:/ho
me/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/resolv:/home/willy/glibc/2.2.4
-1/glibc-2.2.4/hppa-linux/obj/crypt:/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-l
inux/obj/linuxthreads /home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/timez
one/zic -d /home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/install_root/usr/sha
re/zoneinfo -L /dev/null -y ./yearistype africa
make[3]: *** [/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/install_root/usr/
share/zoneinfo/Africa/Algiers] Segmentation fault

running this under gdb gives:

Program received signal SIGSEGV, Segmentation fault.
_dl_debug_vdprintf (fd=0, tag_p=0, 
    fmt=0x173dc <Address 0x173dc out of bounds>, arg=0xbff008d8)
    at dl-misc.c:101
101       while (*fmt != '\0')
(gdb) bt
#0  _dl_debug_vdprintf (fd=0, tag_p=0, 
    fmt=0x173dc <Address 0x173dc out of bounds>, arg=0xbff008d8)
    at dl-misc.c:101
#1  0x4100e468 in _dl_dprintf (fd=2, 
    fmt=0x173dc <Address 0x173dc out of bounds>) at dl-misc.c:273
#2  0x41012454 in __assert_fail (
    assertion=0x15314 <Address 0x15314 out of bounds>, file=0x0, line=62, 
    function=0xbff008d8 "") at dl-minimal.c:190
#3  0x41002e88 in elf_get_dynamic_info___3 (l=0x2) at rtld.c:62
#4  0x41002f90 in _dl_start (arg=0xbff004f4) at rtld.c:172
#5  0x41002ac8 in _dl_start_user () at rtld.c:135
(gdb) 

It looks to me like the problem occurred in frame #3 where
elf_get_dynamic_info was passed `2' as a value.  Bizarrely, this is the
address of a stack variable (take a look in rtld.c), so I am stumped and
I've been working on more interesting stuff instead.  I tried several
times to attract BenC's attention on this and didn't get anywhere.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Building from scratch.

[Carlos O'Donell Jr.]

> 
> Mmm.  I would expect it to not work.  My build dies when it uses part of itself
> in the install:
> 
> /home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/elf/ld.so.1 --library-path 
> /home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj:/home/willy/glibc/2.2.4-1/g
> libc-2.2.4/hppa-linux/obj/math:/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/
> obj/elf:/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/dlfcn:/home/willy/g
> libc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/nss:/home/willy/glibc/2.2.4-1/glibc-2.2.
> 4/hppa-linux/obj/nis:/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/rt:/ho
> me/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/resolv:/home/willy/glibc/2.2.4
> -1/glibc-2.2.4/hppa-linux/obj/crypt:/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-l
> inux/obj/linuxthreads /home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/timez
> one/zic -d /home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/install_root/usr/sha
> re/zoneinfo -L /dev/null -y ./yearistype africa
> make[3]: *** [/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/install_root/usr/
> share/zoneinfo/Africa/Algiers] Segmentation fault
> 
> running this under gdb gives:
> 
> Program received signal SIGSEGV, Segmentation fault.
> _dl_debug_vdprintf (fd=0, tag_p=0, 
>     fmt=0x173dc <Address 0x173dc out of bounds>, arg=0xbff008d8)
>     at dl-misc.c:101
> 101       while (*fmt != '\0')
> (gdb) bt
> #0  _dl_debug_vdprintf (fd=0, tag_p=0, 
>     fmt=0x173dc <Address 0x173dc out of bounds>, arg=0xbff008d8)
>     at dl-misc.c:101
> #1  0x4100e468 in _dl_dprintf (fd=2, 
>     fmt=0x173dc <Address 0x173dc out of bounds>) at dl-misc.c:273
> #2  0x41012454 in __assert_fail (
>     assertion=0x15314 <Address 0x15314 out of bounds>, file=0x0, line=62, 
>     function=0xbff008d8 "") at dl-minimal.c:190
> #3  0x41002e88 in elf_get_dynamic_info___3 (l=0x2) at rtld.c:62
> #4  0x41002f90 in _dl_start (arg=0xbff004f4) at rtld.c:172
> #5  0x41002ac8 in _dl_start_user () at rtld.c:135
> (gdb) 
> 
> It looks to me like the problem occurred in frame #3 where
> elf_get_dynamic_info was passed `2' as a value.  Bizarrely, this is the
> address of a stack variable (take a look in rtld.c), so I am stumped and
> I've been working on more interesting stuff instead.  I tried several
> times to attract BenC's attention on this and didn't get anywhere.
> 
> -- 
> Revolutions do not require corporate support.

That's odd, I built it fine. And went back and rebuilt the rest of GCC 
while I was at it (had to symlink ./src/linux/include/linux and 
./src/linux/include/asm so that they would sit in 
-isystem $DEST/hppa-linux/include used by the last bits of xgcc)

What is running at the moment? One of the binutils or gcc?
It should most definately not segfault in any of the _dl_xxxxx routines ;)

I grabbed the glibc2.2.4 from the debian pool (orig.tar.gz), then applied
the 2.2.4-1 patch, followed by running the glibc22-hppa.dpatch (since I
don't have any deb tools).

The last two patches should probably have been run in the reverse order,
could this be the crux?

I'm still very confused about the ia64 stuff that wants to get touched
by the glibc22-hppa.dpatch?

Although I've built it all without failing... I have yet to test the
new system.


I will:

- Test the compiler by building a new kernel.
- Test glibc on a 712/60.
- Try to reverse the patching order and see if it compiles.

Cheers,
Carlos.

Re: [parisc-linux] Building from scratch.

[Matthew Wilcox]

On Tue, Aug 28, 2001 at 03:22:21PM -0400, Carlos O'Donell Jr. wrote:
> That's odd, I built it fine.

Yes, but you were crosscompiling.  `make install' is very different
with a crossbuild.

> What is running at the moment? One of the binutils or gcc?
> It should most definately not segfault in any of the _dl_xxxxx routines ;)

THe program which is being run is
/home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/timezone/zic; glibc
is making sure it's run with the new ld.so and all the new versions of
the libs.

Have you actually tried installing glibc 2.2.4-1 on a live system and
running programs with it?

> I grabbed the glibc2.2.4 from the debian pool (orig.tar.gz), then applied
> the 2.2.4-1 patch, followed by running the glibc22-hppa.dpatch (since I
> don't have any deb tools).
> 
> The last two patches should probably have been run in the reverse order,
> could this be the crux?

It's more likely that one of the other debian patches conflicts with
what we're doing.  The debian/rules file will apply the patches in the
debian/patches directory in the order given by debian/patches/0list.
I seem to remember a couple of other diffs that need to get applied...

> I'm still very confused about the ia64 stuff that wants to get touched
> by the glibc22-hppa.dpatch?

That's changing all the testandset to trylock.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Building from scratch.

[Carlos O'Donell Jr.]

> 
> Yes, but you were crosscompiling.  `make install' is very different
> with a crossbuild.
> 

What are the major differences? Crosscompiling vs. Crossbuild?
Better yet, where can I learn about those difference?

> 
> THe program which is being run is
> /home/willy/glibc/2.2.4-1/glibc-2.2.4/hppa-linux/obj/timezone/zic; glibc
> is making sure it's run with the new ld.so and all the new versions of
> the libs.
> 

So the native build of zic barfs. I'm not even sure if zic runs when
you compile glibc by hand? Hrm... zic.c is 52,000 loc.. eww.


> Have you actually tried installing glibc 2.2.4-1 on a live system and
> running programs with it?
> 
> It's more likely that one of the other debian patches conflicts with
> what we're doing.  The debian/rules file will apply the patches in the
> debian/patches directory in the order given by debian/patches/0list.
> I seem to remember a couple of other diffs that need to get applied...

Question:
In theory since those patches are changes that haven't been merged upstream,
should the only requirements be:

- Have 2.2.4 Original
- Carry out any one of the dpatch's since they are dif'd against 2.2.4 Original
- Then carry out the 2.2.4-1 patch

For x86 Cross Compiler, the only requirement would be:
- Apply the dpatch's that are critical to the running hppa port

Quesiton:
If the pool has the hppa changes commented out in the 0list file, does
that mean that glibc2.2.4 is not available for hppa yet? (Since it fails to 
compile? The first error probably being the Elf32_Addr* problem with
that '& 3' fixed by a cast to (unsigned int)).

> 
> That's changing all the testandset to trylock.
>

Why would that be in the hppa dpatch?

Cheers,
Carlos. 

Re: [parisc-linux] Building from scratch.

[Matthew Wilcox]

On Tue, Aug 28, 2001 at 04:36:39PM -0400, Carlos O'Donell Jr. wrote:
> What are the major differences? Crosscompiling vs. Crossbuild?
> Better yet, where can I learn about those difference?

I don't think the differences between cross and native builds are
documented anywhere.

> So the native build of zic barfs. I'm not even sure if zic runs when
> you compile glibc by hand? Hrm... zic.c is 52,000 loc.. eww.

I would say it dies in the dynamic linker before zic is entered.

> Question:
> In theory since those patches are changes that haven't been merged upstream,
> should the only requirements be:
> 
> - Have 2.2.4 Original
> - Carry out any one of the dpatch's since they are dif'd against 2.2.4 Original
> - Then carry out the 2.2.4-1 patch

No.  The 2.2.4-1 patch adds the debian-specific patches to the tarball.
There's nowhere to get the hppa patch from if you don't apply the
2.2.4-1 patch.

> Quesiton:
> If the pool has the hppa changes commented out in the 0list file, does
> that mean that glibc2.2.4 is not available for hppa yet? (Since it fails to 
> compile? The first error probably being the Elf32_Addr* problem with
> that '& 3' fixed by a cast to (unsigned int)).

glibc 2.2.4 is indeed not yet available for hppa.  As it says in the
release announcement.

> > 
> > That's changing all the testandset to trylock.
> >
> 
> Why would that be in the hppa dpatch?

Because we can't implement testandset atomically & efficiently on hppa.
The places which use testandset actually just need trylock.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Building from scratch.

[Carlos O'Donell Jr.]

> > 
> > I have no enthusiasm for working on glibc.  Please, someone, take it
> > off my hands.
> > 
> > -- 
> > Revolutions do not require corporate support.
> >

Wow, do I feel like a knuckle head :}

So after allowing myself to sip a good cup of straight black joe,
I think I found _the_ problem with my setup.

I use a makefile + perl to automate the download/setup/install of
the toolchain and associated files (atleast that's what I'm working 
on...)

I noticed the following error in my makefile:

 --prefix=$(DEST)/hppa-linux\
--with-headers=$(SRC)/linux/include \

Which is definately not a good thing! Since both get concatenated
into a single --prefix. My apologies Matthew, I did not want to waste
your time or mine on something so trivial. Sadly, when trying for the
eleventybazillionth time ... you might miss the _missing_ space in
the configure line.

Please forgive me... once I finish the setup, would you like me to send
the list a new ./toolchain/index.html for the site?

Some things I've noticed that I will add to index.html:

a) Must remember to set CC to hppa-linux-gcc (It hurts when you forget)
	= glibc's configure always seeks out gcc and there seems to
	= be no --with-cc=?? option
	= The wrong gcc also hurts because configure adds 
	= -isystem /your/local/gcc/include rather than the proper one.

b) Must remember to add $DEST/bin to path (needed for building gcc)
	= gcc is the first complainer since it needs hppa-linux-ar.

c) If not running debian, must run:

[glibc-2.2.4]sh ./debian/patches/glibc22-hppa.dpatctch -patch /your/hppa/glibc
(This patch touches some ia64 stuff?)

I wonder how many people build the toolchain from source?
I love this crosscompiler! Especially since our dual PIII box can still
compile the pants of any of our HPPA boxes (especially the 715/50's ;)

<Carlos looks back at the compile, still chugging, much father!>

OH MY GOD!
It compiled with 0 errors and 0 warnings...

I'm estatic!

I'm too frenetic to actually attempt to xc something and test out glibc :}


I'll bet you lied about the patch failing just to taunt me!
I bested you! ;)


Cheers,
Carlos.