At 1:16 AM +0900 5/3/05, Izumi Tsutsui wrote:
>> I'm trying to find individuals who have successfully built with _macppc_
>> tools.  Cross-building appears to do things differently, in spite of
>> suggestions to the contrary.
>
>build.sh always do cross-building even if target == host.

I understand that this is the theory.  I'm not convinced this is the
practice.  Not that I'm saying it will fail, but have you tried building
any non-macppc userland from macppc?

>>  If I can find someone that can build -current
>> userland with macppc using a cvs up more recent than this past Friday, I
>> will cvs up and again spend twenty plus hours building.  As far as I can
>> tell, the error was in gdb, not gettext.  I probably just didn't get far
>> enough to fail on gettext.
>
>I've tried make build on macppc with April 30 sources and it finished
>alter I added local changes against gettext.
>(BTW gdb is built after gettext)

OK, I will attempt to cvs up using the April 30 date.  Otherwise I'm likely
to just introduce new problems.  It wouldn't be the first time.  I will
report back the results in a couple days.  I

>> If it took NetBSD developers twenty plus hours to build userland, they
>> might be less cavalier about commits that don't compile.
>
>IMHO you should provide exact command you typed and exact error messages
>you got in your problem report.
>(Maybe you specified -jN or something? I've never seen "4 errors"
> or "1 error" messages in my logs)

I have been following the documentation at

http://www.netbsd.org/Documentation/current/#using-anoncvs-pserver

My command has been

./build.sh -O /usr/obj -D /usr/NetBSD-new-build -T /usr/tools build

with variations of -j

./build.sh -j 2 -O /usr/obj -D /usr/NetBSD-new-build -T /usr/tools build
./build.sh -j 8 -O /usr/obj -D /usr/NetBSD-new-build -T /usr/tools build

I have not been able to use the -u option when running 3.99.3 because my
userland is 2.99.12 (the last userland that would compile) and build.sh
complains about the kernel being too new.

The most recent error occured with -j 8 and a 2.99.10 kernel, the most
recent I could find that would reliably run.  Previously I had run all
three -j variations with 3.99.3, none successfully.  Maybe the logs will
have something more informative.  The message I posted was from the
terminal.

tim