On Mon 23 Nov, Todd Whitesel wrote:
> > Anyway, I tried again (after building compile_et and make_cmds) and it
> > died at a different point, when constructing libc - ld complaining
> > about various things. Hmmm.... this is fun.
> 
> Was it this?
> 
> building shared c library (version 12.33)
> ld -x -shared  -o libc.so.12.33    --whole-archive libc_pic.a --no-whole-archive   
> ld: libc_pic.a(brk.so): relocation for internal symbol expected at 0x40
> ld: libc_pic.a(sbrk.so): relocation for internal symbol expected at 0x38
> ld: internal error: libc_pic.a(brk.so): claim_rrs_internal_gotslot at 0x40: no reserva
> tion
> *** Error code 1
> 
> Stop.
> 
> If so then you are just as screwed as I am. The first 'make build' went fine,
> but when I went to do the stage 2 bootstrap (to borrow a gcc term) it barfed
> right here.

Yep. I gave up. When I did make build the first time, without applying any of the
various patches, it worked fine till it installed ld.so (with bugs). When the
patches were applied, it died even earlier. Weird.

> 
> > Can anyone provide me with a comprehensive guide to how to get the stupid
> > thing to work correctly? Everyone else seems to be getting on fine. Should I
> 
> Actually it's only you & me who are trying to build from source right now.
> Everyone else is using snapshots while Todd V. and Charles Hannum work on the
> toolchain problems. Some fixes were recently checked in, but I haven't supped
> them just yet. I update my i386 and arm32 -current machines pretty much in
> lockstep and the i386 is still tied up helping to isolate a kernel problem
> that Patrick Welche reported.

Not any more. I've abandoned it. I'm going to wait till some nice person
produces a snapshot, preferably with egcs.

> 
> Once I have exhausted what I can do to help on that, I will reapply my patches
> to a fresh SUP and see how that goes (after backing out the userland binaries
> again, that is: tar --unlink -xvf from CD is your friend).
> 
> What worries me is I have no idea if I am supposed to explicitly build+install

Don't know this. On a few of the builds, according to one of the Makefiles (I
this it's /usr/src/Makefile) - i386? alpha? it does install egcs and on everything
else, incl. arm32 it installs gcc 2.7.2.2. The gcc 2.7.2.2 in the 19981114 sources
was a newer version that the one in my snapshots (myc1 in my snapshots, myc2 (thinks)
in the sources I grabbed.

> egcs at some point; I ended up doing that on i386 because 'make build' brought
> egcs in but did it incorrectly, and a second 'make build' from the same
> sources bombed with this:
> 
> c++ -O  -Werror   -I/usr/include/g++ -I/usr/src/gnu/lib/libstdc++/../../dist/lib
> stdc++ -c /usr/src/gnu/lib/libstdc++/../../dist/libio/builtinbuf.cc
> In file included from /usr/src/gnu/lib/libstdc++/../../dist/libio/iostreamP.h:26
> ,
>                  from /usr/src/gnu/lib/libstdc++/../../dist/libio/builtinbuf.cc:
> 30:
> /usr/src/gnu/lib/libstdc++/../../dist/libio/libioP.h:94: syntax error before `('
> [ lots more error messages, same error but different line number ]
> 

I've reinstalled my entire system from scratch, the previous install being
screwed up by my messing around with the sources. And now ncurses won't work.
Every time I've installed it before it has worked fine, but building from
pkgsrc fails. If I build it normally, without shared libs it works fine but
shared libs produces core dumps everywhere. Very, very strange. The packaged
version for arm32 on ftp.netbsd.org doesn't work on my system (I think
it's been incorrectly packaged).

Ho, hum.
Have fun, won't you ;-))

tim

> Todd Whitesel
> toddpw @ best.com
> 
> 
> 

-- 
tim@auroral.freeserve.co.uk