Joe Reed | 20 Mar 01:54 2002
Picon

Re: build failed

did you do a 'make build' or 'sh build.sh' ??

if you're using make build, your toolchain is not necessarily rebuilt.  you 
can rebuild it with 'sh build.sh -t' then go back to 'bake build'  or just 
build userland with 'sh build.sh' (the prefered way, or so i'm told ;-)

--joe

On Tuesday 12 March 2002 10:23, Werner Backes wrote:
> Hi,
>
> I'm trying do build userland  with the latest source but this
> fails with:
>
> CC=/usr/src/tools/tools.NetBSD-1.5ZA-i386/bin/i386--netbsdelf-gcc
> /usr/src/tools/tools.NetBSD-1.5ZA-i386/bin/i386--netbsdelf-lint
> -chapbxzF -w -X 272 -d /test/usr/include -D_LIBC -DNLS -DYP
> -DHESIOD -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT
> -I/usr/src/lib/libc/include -DINET6 -D__DBINTERFACE_PRIVATE
> -I/usr/src/lib/libc/../../libexec/ld.elf_so
> -I/usr/src/lib/libc/dlfcn -DWITH_RUNE -DRUNEMOD_MAJOR=3
> -D_PATH_LOCALEMODULE=\"/usr/lib/runemodule\" -DRESOLVSORT
> -I. -DPOSIX_MISTAKE -DPORTMAP -DFLOATING_POINT -i LintSysNoerr.c
>
> /test/usr/include/machine/atomic.h(49): warning: conversion from
> 'unsigned long' may lose accuracy [132]
> *** Error code 1
>
> Stop.
> nbmake: stopped in /usr/src/lib/libc
(Continue reading)

Andrew Brown | 20 Mar 02:56 2002
Picon

Re: build failed

>Btw, I wonder why the tool dir is still "tools.NetBSD-1.5ZA-i386",
>I would have excepted "1.5ZB". I don't set TOOLDIR in my thenvironment
>so I think this cannot be the problem.

that's dragged from the *running kernel*, so if you haven't built and
started a new kernel...

--

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior <at> daemon.org             * "ah!  i see you have the internet
twofsonet <at> graffiti.com (Andrew Brown)                that goes *ping*!"
andrew <at> crossbar.com       * "information is power -- share the wealth."

Werner Backes | 20 Mar 18:29 2002
Picon

Re: build failed

Joe Reed wrote:
> if you're using make build, your toolchain is not necessarily rebuilt.  you
> can rebuild it with 'sh build.sh -t' 

Yes, that's what I did. But the problems seems to be someting else:
Christos told me to change "unsigned long" in atomic.h to "u_int32_t".
This solves the problem. Thanks! :)

Werner

Michael Graff | 27 Mar 06:51 2002

i386 smp branch


I really see this as stagnating here.  The branch has failed to
compile more than not recently, and all of these problems stem from
the world changing but the i386 branch being held back in time.

What are the plans for the future of i386 SMP?

--Michael
Bill Sommerfeld | 27 Mar 08:29 2002
Picon

Re: i386 smp branch

> The branch has failed to
> compile more than not recently, and all of these problems stem from
> the world changing but the i386 branch being held back in time.

The branch has been synched with the trunk about once a month.

Look at the date at the top of the branch's version of
arch/i386/MP-UPDATING for a timestamp of -current where it will
compile.

					- Bill

Michael Graff | 27 Mar 10:23 2002

Re: i386 smp branch


If I have patches (like sync'ing up with isdn changes) can I commit
them?

The pool API changes as well, although I don't think I have all that
right.  That said, my box is running two setiathome's and has
compiled /usr/src 12 times now.

--Michael

Bill Sommerfeld <sommerfeld <at> orchard.arlington.ma.us> writes:

> > The branch has failed to
> > compile more than not recently, and all of these problems stem from
> > the world changing but the i386 branch being held back in time.
> 
> The branch has been synched with the trunk about once a month.
> 
> Look at the date at the top of the branch's version of
> arch/i386/MP-UPDATING for a timestamp of -current where it will
> compile.
> 
> 					- Bill

Gmane