Since one week or two, build.sh fails on a SIGSEGV, always at the same point: just before building c libraries (when running ranlib?)

	building standard c library
	*** Signal 11

	Stop.
	nbmake: stopped in /usr/src/lib/libc
	*** Error code 1

When started over (with an extra -o), it runs exactly one step ahead and stops on the same signal:

	building standard c library
	/bulk/snapshots/20020612/tooldir/bin/sparc64--netbsd-ranlib libc.a
	building profiled c library
	*** Signal 11

	Stop.
	nbmake: stopped in /usr/src/lib/libc
	*** Error code 1

and then one more time when restarted again:

	building profiled c library
	/bulk/snapshots/20020612/tooldir/bin/sparc64--netbsd-ranlib libc_p.a
	building shared object c library
	*** Signal 11

	Stop.
	nbmake: stopped in /usr/src/lib/libc
	*** Error code 1

Launched an other time, it proceeds without any other problem:

	building shared object c library
	/bulk/snapshots/20020612/tooldir/bin/sparc64--netbsd-ranlib libc_pic.a
	building shared c library (version 12.84)
	/bulk/snapshots/20020612/tooldir/bin/sparc64--netbsd-ld -nostdlib -x -shared -soname libc.so.12 -o libc.so.12.84  /bulk/snapshots/20020612/destdir/usr/lib/crtbeginS.o  --whole-archive libc_pic.a  --no-whole-archive   -L/bulk/snapshots/20020612/destdir/usr/lib -L/bulk/snapshots/20020612/destdir/usr/lib  -R/usr/lib -R/usr/lib  /bulk/snapshots/20020612/destdir/usr/lib/crtendS.o
	[...]


This happens on a sparc64 hardware (Netra X1) running a 64-bit kernel (roughly GENERIC) and a 64-bit userland, wether they were natively build, cross-build or fetched from releng. Everything is alright when build.sh, targeting sparc64, is a cross-building process (e.g. on an i386). And build.sh goes its way successfully when the 64-bit hardware runs a GENERIC32 kernel and a 32-bit (e.g. sun4m) userland (this is somehow a cross-build)...


So, here is the point: what is the now-days status of 64-bit compilers/linkers/loaders/libraries/programs, native sparc64 or cross-to-other-arch, running on sparc64 systems?

They seem mostly operative but with strange weirdnesses: large negative size or counters, etc.


--SE


P.S.: If useful for anybody, here is a way to plug a 32-bit environment on a 64-bit machine:
- build or fetch a sparc (sun4m) userland (binary/sets/*.tgz are fine)
- build a 32-bit sparc64 kernel and boot files (cross-build is safer?)
- install them
- populate /dev with a 64-bit MAKEDEV, not the sparc (sun4m) one.

Beware of anything relying on uname ((1) or (3)) which still return a sparc64 machine. For example, when trying to build a 32-bit X11 on a sparc64 hardware: imake tells the c compiler to use 64-bit options which are rejected by the 32-bit compiler. Either build X11 on a sparc (sun4m) hardware or, dirtier, patch imake to force a -D__sparc__ instead of -D__%s__ uts.machine...

---
Sam Erde @ Donf
"bin ich auch eine GmbH: keine Haftung..."




Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com