headers
Joe Reed | 20 Mar 2002 01:54
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)

Permalink | Reply | 0 comments |
headers
Andrew Brown | 20 Mar 2002 02:56

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."
Permalink | Reply | 0 comments |
headers
Werner Backes | 20 Mar 2002 18:29
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
Permalink | Reply | 0 comments |
headers
Michael Graff | 27 Mar 2002 06:51
Gravatar

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
Permalink | Reply | 0 comments |
headers
Bill Sommerfeld | 27 Mar 2002 08:29
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
Permalink | Reply | 1 comment |
headers
Michael Graff | 27 Mar 2002 10:23
Gravatar

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
Permalink | Reply | 0 comments |

Gmane