My attempt with 1.5.3 on a LC040 got me 90% there with just
libc.so built with softfloat.  That said, there were still a lot of
cores dropped on booting by different programs which were statically
linked.

There seemed to be 3 class of programs.

- No f instructions - these worked fine.
- accidential f instructions, say via libraries.  Think printf and
friends.  Fixing libc.so fixed most of those, with no other changes,
though the staticly linked ones required rebuilding.
- Floating point ops in the programs itself.  Squeak in my case.
One had to rebuild with -msoft-float for these to work.

You're right that libc, libm, and a few other dynamic libraries
would catch a good number of the places where things fall 
over now.  You still need ls relinked.  I am addicted to ls -l :-)

cheers

bruce


David Brownlee <abs@netbsd.org> wrote:
> On Fri, 6 Jun 2003, Riccardo Mottola wrote:
> 
> > on 6/5/03 11:44 AM, David Brownlee at abs@netbsd.org wrote:
> >
> > > If some LC040 owners would like to send me the output of
> > >
> > > sysctl hw.model hw.machine hw.machine_arch;grep '^cpu' /var/run/dmesg.boot
> > >
> > > I'll update devel/cpuflags to set compiler flags automatically
> > > for them :)
> > I'll do that as soon as I can boot using the unofficial port (right now the
> > page has exceeded transfer quota). as for now the official 1.6 kernel
> > seg-faults at startup.
> >
> >
> > -riccardo
> >
> > PS: If I get the LC475 running I could provide an unpatched kernel to use
> > for LC machines ? maybe even a installer kernel?
> 
> 	I understood the kernel was fine as it doesn't use FPU
> 	instructions - its only the userland.
> 
> 	Just an off the wall thought - how much better are things if
> 	just the libraries are compiled with -msoft-float? Various
> 	other ports have conditionals to pick a different libm or
> 	similar based on cpu type.
> 
> -- 
> 		David/absolute          -- www.netbsd.org: No hype required --