Re: NetBSD-HEAD amd64 refuses to build

2013-12-30 Thread Andreas Gustafsson 
Thomas Mueller wrote:
 Where do I get a serial console, and how do I connect it to a
 computer when there are no serial ports?

My suggestion would be not to bother with the serial console, but
instead take a picture of the screen using a digital camera, type 
bt at the ddb prompt, take another picture, put the pictures in
some public location on the web (e.g., flickr or dropbox), and
file a problem report including the URLs of the pictures at

  http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd

-- 
Andreas Gustafsson, g...@gson.org

Re: NetBSD-HEAD amd64 refuses to build

2013-12-30 Thread Thomas Mueller 
 Thomas Mueller wrote:
  Where do I get a serial console, and how do I connect it to a
  computer when there are no serial ports?

 My suggestion would be not to bother with the serial console, but
 instead take a picture of the screen using a digital camera, type
 bt at the ddb prompt, take another picture, put the pictures in
 some public location on the web (e.g., flickr or dropbox), and
 file a problem report including the URLs of the pictures at

   http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd

--
 Andreas Gustafsson, g...@gson.org

I don't have a digital camera or smartphone.

Besides, a digital camera would lose all the messages that raced past on the 
screen.

I tried reboot 0x100 but couldn't find where the dump was.  I ran
ls -rtl in /media/zip0/var and subdirectories but couldn't find any messages 
from crash time.

This was from FreeBSD using mount point /media/zip0.

Regarding send-pr, I might be able to copy this shell script to FreeBSD, giving 
it a different name, like nbsend-pr or send-pr-netbsd, to avoid conflict with 
FreeBSd's send-pr.  I'd have to edit MAIL_AGENT and maybe some paths in the 
script.

But I figure to have very limited time for NetBSD in upcoming days and weeks.

FreeBSD 10.0-RELEASE is around the corner, and interesting things are happening 
with 10.0 and 11.0-HEAD amd64 and i386: much more promising than any NetBSD on 
my computer system.

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-29 Thread Thomas Mueller 
   Just to ask the obvious: did you try without the -c, and if so, what
   happened?

  Sure I tried without -c, went into the debugger prompt.

 At point in the boot process did you end up in the debugger? (What was
 on the screen?) Did a backtrace bt give any clues?

 Cheers,

 Patrick

Basically, I'm lost with the debugger, and the best I can do is type reboot.

Is there any documentation?

But I don't think the debugger could really help me.

I remember in the boot process getting past athn0, so that was detected 
apparently satisfactorily.

I have packages built for amd64 but nothing that survives for NetBSD-current 
i386, and I don't want to restart from scratch building packages for amd64.

I remember building modular-xorg from pkgsrc, but startx failed on inability to 
find display.  This also happens with OpenBSD 5.4 Live USB from 
liveusb-openbsd.sourceforge.net
which was supposed to have been already configured and ready to go.

There needs to be a way to single-step through the boot process; otherwise, 
boot messages whiz past too fast to be readable, and I still don't know any way 
to capture these messages to a file when boot falls short.

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-29 Thread Thomas Mueller 
  Basically, I'm lost with the debugger, and the best I can do is type
  reboot.

 As Patrick suggested, please try typing bt in the debugger, to get a
 back-trace.

  Is there any documentation?

 Yes - see man 4 ddb

  But I don't think the debugger could really help me.

 It certainly won't help if you don't try, and don't listen to other
 people who are trying to help you.

  I remember in the boot process getting past athn0, so that was
  detected apparently satisfactorily.

  I have packages built for amd64 but nothing that survives for
  NetBSD-current i386, and I don't want to restart from scratch building
  packages for amd64.

 If you can't get the kernel running and stable, you are a long ways
 away from having to think about building packages.

  I remember building modular-xorg from pkgsrc, but startx failed on
  inability to find display.  This also happens with OpenBSD 5.4 Live
  USB from liveusb-openbsd.sourceforge.net which was supposed to have
  been already configured and ready to go.

  There needs to be a way to single-step through the boot process;
  otherwise, boot messages whiz past too fast to be readable, and I
  still don't know any way to capture these messages to a file when boot
  falls short.

 Try using a serial console and capturing the output.

 The messages are also stored in the kernel's message buffer, where the
 debugger can access them.

 And, if you were to type reboot 0x100 you could force a crash dump.


| Paul Goyette

Fortunately, at
http://releng.netbsd.org/cgi-bin/builds.cgi

there is a link to documentation including man pages, so I can check a man page 
even when not running NetBSD (just did for ddb).

I had packages built for NetBSD-current amd64 before the last ill-fated update.

Where do I get a serial console, and how do I connect it to a computer when 
there are no serial ports?

Motherboard has a serial header.  But serial and parallel ports have greatly 
gone out of style in recent years along with SCSI and floppy disks.

Where would the kernel's message buffer be found?  Would it be 
/var/log/messages ?

I can examine that even from FreeBSD.

I didn't know about reboot 0x100.  Where would the crash dump go?  Would it 
be /var/crash ?

Thanks for info, now I have something to try, even if it's a stab in the dark.

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-28 Thread Thomas Mueller 
 On Sat, Dec 28, 2013 at 01:07:45PM +, Thomas Mueller wrote:
  After clearing src tree, but saving and putting back CVS subdirectory, I 
  was able to redownload the src tree.

  I was then successful (?) building and installing NetBSD-current for i386 
  and amd64, building from amd64.

  But the resulting installation proved nonbootable; apparently init died.

  I tried
  boot netbsd-sandy7 -c


 Just to ask the obvious: did you try without the -c, and if so, what
 happened?

 Patrick

Sure I tried without -c, went into the debugger prompt.  

I remember trying -c before on NetBSD 6-STABLE previously with same result, 
getting 
uc (followed by rectangular cursor with blinking horizontal stripes)
and no response to anything from the keyboard.

I thought xhci might be the snag, but subsequently figured the fault was 
probably somewhere within userland rather than the kernel.

I see I have a live USB stick with NetBSD 6.99.11 i386, made from a system 
cross-build from FreeBSD.

I might be able to use that if I try to build NetBSD-current again, also have 
more-recent USB-stick installations of NetBSD 6.1_STABLE, i386 and amd64.

I could also try to cross-compile from FreeBSD but would want to use a newer 
GCC from ports as opposed to 4.2.1 in the base system.

Now on amd64 and i386, with releng-10, GCC is by default not built for FreeBSD 
base system, clang taking its place, but various releases and snapshots of gcc 
are available in the ports.

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-19 Thread Robert Elz 
Date:Wed, 18 Dec 2013 22:28:47 -0800 (PST)
From:Thomas Mueller mueller6...@bellsouth.net
Message-ID:  365452.37125...@smtp111.sbc.mail.bf1.yahoo.com

  | I have e-mail set up for msmtp and mpop.

A PR is just an e-mail message with a particular body format, you can use
any mail program you like to send it - if you can't make the send-pr program
use the mailer that you have that works, then you can just use send-pr to
get the correct format, when you've done editing, save the file somewhere
you can remember its name (/tmp/PR or something) then use your mailer to
send that file (it goes to gnats-b...@gnats.netbsd.org)

  | I tried with postfix, but it failed to send allegedly because my hostname
  | was different from e-mail address: not a problem with msmtp.

I doubt that could be quite what it complained about, but I'm not a postfix
user (let alone admin) so I really have no idea.

But this is an example of what people have been saying (and I repeat
below) - there you described what happened, as you observed it, with
your interpretation.  Don't do that - include the actual message from
(in this case, postfix) and whatever config you did to it, what your
hostname is set to, what was in the headers of the e-mail you were
sending, ...  With all the info, others can duplicate your setup
(if they don't simply know what the problem or mis-config is) and
see if they can make it happen for them, which is the first step in
solving problems - it is really hard to work out what is going wrong when
you can't make it happen.

And put just one problem in one message, with a suitable subject header
(don't just reply to some other random message and jump into a new issue.)

  | I believe e-mail clients configure SMTP and POP3 servers independent of
  | system sendmail, and independent of hostname on the computer.

Yes, many do, I use nmh, and it can be configured to use anything as
the SMTP server.  Using something off the local system is always a bit
risky though, as those clients typically have no queue  retry mechanism,
so if the SMTP server you configured isn't available, or can't be reached,
then the mail just fails (sometimes even silently, depending upon the
client and how it is used).  A local MTA avoids that problem - it should
always be running and of course, is always reachable.

  | Would www interface work with lynx or links?  I built those from pkgsrc.

I have never tried, but I can't think of a reason why not - it is all just
text after all.   But there's no reason that you really have to send from
the system in question (it can be easier if you have output to show that
you want to attach) - anything that can connect to the web should allow you
to fill in the PR form there.

  | But some problems don't produce console output error messages,

Lots of problems don't - in fact, the vast majority don't.  When you were
asked for that, it wasn't that the green text was what was wanted,
necessarily - what people need to know is exactly what happened, as precisely
as possible, with as much information as possible (getting all the trivial
little details right if you possibly can - it can be a big difference if 
something reports a problem as 0x1c compared to 0x1c000 ...)

What you shouldn't do (at least not without a lot of experience) is guess
at the problem cause, or attempt what you think should be a solution, and
then complain about that not working (you can try stuff if you want,  but
if you want help, describe the original problem as accurately as you can,
and don't be afraid of adding information, even if you suspect it might
be useless).

  | like the screenblank bug in NetBSD 5.x

The context for that one eludes me.

  | and getting dark screen after returning from X.

Unfortunately, quite a lot of the X drivers don't reset the graphics
to dumb mode perfectly when they quit - some are much worse than others.
Mostly people don't care all that much, as usually once X is running,
people just leave it running, and never exit (just shutdown or reboot).

So while the problem is a definite bug, and it would be nice to get it
fixed, it just isn't very high on anyone' priority list (it also typically
isn't a NetBSD problem - except in as much as NetBSD uses Xorg code).

  | Also, on NetBSD-current, when using more than one virtual terminal,
  | no more response to keyboard input, though most, but not all the time,
  | unplugging the  mouse brings back the keyboard.

I haven't seen that one myself, but I suspect that a recent fix to the
USB system (very recent fix) might just have done away with that (just
from what I read on the list and the symptoms reported, along with your
description).   So perhaps try a more up to date (like last day or two)
version of current...

kre

Re: NetBSD-HEAD amd64 refuses to build

2013-12-18 Thread Robert Elz 
Date:Wed, 18 Dec 2013 09:48:46 + (UTC)
From:Thomas Mueller mueller6...@bellsouth.net
Message-ID:  962636.61603...@smtp120.sbc.mail.bf1.yahoo.com

  | A different compiler I might use would be a newer version of gcc

That can cause problems - or would if you really were using it the way
that you believe...  When building NetBSD, the compiler that needs to
be on the host system (the one you're talking about) is used to build
the tools - which in particular, means to build the compiler that the
NetBSD build system wants to use, which comes from the NetBSD sources
(it also builds NetBSD's make, and a bunch of other stuff that are needed).

Once those exist, everything else (everything that you will eventually
install) is built using the compiler that has been built that way.

Given that, provided the compiler you have is good enough to build gcc
itself, it really doesn't matter which version it is.

  | A problem with send-pr is where to specify the outgoing SMTP server.

If you don't have e-mail set up, use the web interface instead, you
can find it on www.netbsd.org - in the menu bar neat the top of the page,
hover over Support, then drop down to Report a bug in the menu that
appears, and click on that.

kre

Re: NetBSD-HEAD amd64 refuses to build

2013-12-18 Thread Alan Barrett 

On Wed, 18 Dec 2013, Thomas Mueller wrote:
A different compiler I might use would be a newer version of 
gcc as opposed to an entirely different compiler (what else for 
NetBSD, other than llvm/clang?)


If you really want the pain of using an unsupported compiler, go 
ahead, but don't expect much help.  Unless you are a expert with 
compilers, and an expert with the NetBSD build system, and maybe 
also an expert with other aspects of NetBSD, I strongly recommend 
that you NOT try to use any compiler other than (1) the compiler 
that's already on your host system, which will be used to build 
the tools, and (2) the compiler that's automatically built as 
part of build.sh's tools phase, which will be used to build 
everything else.


I've complained about crashes, instabilities and comical 
failures in NetBSD since summer 2011, and wondered if it was 
worth the trouble.


Yes, you have, but the complaints that I saw did not include 
enough details.  For example, it's not enough to say there were 
some green messages on the console, you need to copy those 
messages (or a summary of them) into the bug report.


A problem with send-pr is where to specify the outgoing SMTP 
server.  It's easier to set up msmtp or other SMTP client. 
Sendmail is so mysterious, mystic, and postfix is almost as bad.


As long as you have a working mailer (with a frontend that 
understands some subset of the sendmail command line interface) 
you should be able to use send-pr.  I am not sure, but I 
think that msmtp provides a suitable interface, so you can 
make /etc/mailer.conf refer to msmtp.  The default postfix 
configuration shipped with NetBSD is supposed to work without any 
configuration, but if you need to configure a smart host then the 
relayhost paremeter in /etc/postfix/main.cf is the place to do 
it.


If you don't have a working mailer, then you can use the web 
interface to send-pr, as kre mentioned.


--apb (Alan Barrett)

Re: NetBSD-HEAD amd64 refuses to build

2013-12-18 Thread John Nemeth 
On Dec 18,  9:48am, Thomas Mueller wrote:
}
}  Yes, and you can pass -V MAKECONF=/etc/makenetbsd.conf to build.sh
}  to make it use that file instead of /etc/make.conf.

You could, but it would be much better to just follow the
instructions that you've been given.  It would be a lot harder for
people to help you, if you experiment.

}   Now I think I could use a newer gcc from FreeBSD ports if I choose
}   or need to cross-compile NetBSD from FreeBSD.
} 
}   I always use build.sh to build NetBSD system, have never used make
}   directly for that purpose.

 Keep in mind that one of the early things build.sh does is to
build the version of GCC supplied with NetBSD.  After that, everything
is compiled using it as a cross-compiler.  The compiler on the host
system is only used to build the tools.

 It is possible to instruct build.sh to use a different compiler,
but you should stick with as many defaults as possible for now in
order to work out the kinks.  Once you are successfully building,
you can experiment.

} On 
}  I just looked in NetBSD's /etc/mk.conf and found the lines
}  #if BSD_PKG_MK
}  #endif
}  with pkgsrc stuff in between, so those lines are still there.
} 
} I hand-copied it wrong as had John Nemeth before me.  I also might have
} had #define and #include C preprocessor statements on the back of my mind.

 Oops, yes, my bad.  If you follow source-changes, you'll note
that I mostly hack C, not Makefiles.

} Advice in build.sh and BUILDING is to use build.sh instead of directly
} running make.
} 
} A different compiler I might use would be a newer version of
} gcc as opposed to an entirely different compiler (what else for
} NetBSD, other than llvm/clang?)

 pcc

} I've complained about crashes, instabilities and comical failures in NetBSD

 I'm having trouble figuring out how a failure can be described
as comical.

} since summer 2011, and wondered if it was worth the trouble.
} 
} A problem with send-pr is where to specify the outgoing SMTP
} server.  It's easier to set up msmtp or other SMTP client.
} Sendmail is so mysterious, mystic, and postfix is almost as bad.

 Sendmail isn't mysterious to me :-  But, then I've been
configuring and maintaining Sendmail for 20+ years.

 Anyways, if you go to http://www.NetBSD.org/ and look under
Support you'll find a link for Report a bug which takes you to
http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd .  That page
is a web version of send-pr and can be used to report bugs if you
don't have a functioning mail system.

}-- End of excerpt from Thomas Mueller

Re: NetBSD-HEAD amd64 refuses to build

2013-12-18 Thread Thomas Mueller 
   | A different compiler I might use would be a newer version of gcc

 That can cause problems - or would if you really were using it the way
 that you believe...  When building NetBSD, the compiler that needs to
 be on the host system (the one you're talking about) is used to build
 the tools - which in particular, means to build the compiler that the
 NetBSD build system wants to use, which comes from the NetBSD sources
 (it also builds NetBSD's make, and a bunch of other stuff that are needed).

 Once those exist, everything else (everything that you will eventually
 install) is built using the compiler that has been built that way.

 Given that, provided the compiler you have is good enough to build gcc
 itself, it really doesn't matter which version it is.

   | A problem with send-pr is where to specify the outgoing SMTP server.

 If you don't have e-mail set up, use the web interface instead, you
 can find it on www.netbsd.org - in the menu bar neat the top of the page,
 hover over Support, then drop down to Report a bug in the menu that
 appears, and click on that.

 kre

I have e-mail set up for msmtp and mpop.

I tried with postfix, but it failed to send allegedly because my hostname
was different from e-mail address: not a problem with msmtp.

I believe e-mail clients configure SMTP and POP3 servers independent of
system sendmail, and independent of hostname on the computer.

I built modular Xorg from pkgsrc, and on NetBSD-current amd64, X wouldn't
start at all.  I had same problem with OpenBSD 5.4 Live USB
http://liveusb-openbsd.sourceforge.net

Would www interface work with lynx or links?  I built those from pkgsrc.

On new FreeBSD installations, I haven't built X yet: in ports but not
available in base system.

But some problems don't produce console output error messages, like the
screenblank bug in NetBSD 5.x and getting dark screen after returning from X.

Also, on NetBSD-current, when using more than one virtual terminal, no more
response to keyboard input, though most, but not all the time, unplugging the
mouse brings back the keyboard.

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Alan Barrett 

On Sun, 15 Dec 2013, mueller6...@bellsouth.net wrote:

I tried to build this time with
MKLLVM=yes
HAVE_LLVM=yes
MKLIBCXX=yes
and again failed.


OK ...


=== build.sh command:./build.sh -m amd64 -M ../obj.amd64.llvm -B 
nb20131214-llvm -T ../tooldir.amd64.llvm -V MKLLVM=yes -V HAVE_LLVM=yes -V 
MKLIBCXX=yes -U -j 9 distribution kernel=GENERIC
=== build.sh started:Sat Dec 14 08:58:39 UTC 2013
=== NetBSD version:  6.99.28
=== MACHINE: amd64
=== MACHINE_ARCH:x86_64
=== Build platform:  NetBSD 6.99.23 amd64
=== HOST_SH: /bin/sh


 [...]


--- initiator.po ---
error: unable to rename temporary 'initiator.po-fe88e164' to output file 
'initiator.po': 'No such file or directory'
1 error generated.


 [...]


--- initiator.po ---
*** [initiator.po] Error code 1
nbmake[6]: stopped in /BETA1/netbsd-HEAD/usr/src/external/bsd/iscsi/lib


Is that unable to rename temporary message the very first error 
message, or were there others earlier?  (There will be other 
messages relating to initiator.po earlier in your build log, in 
the part that you did not paste.)


Is this problem repeatable, and does it also appear with -j1?

--apb (Alan Barrett)

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Thomas Mueller 
 A clean build with no special options means at least this:

  * clean source tree, with no extra or modified files (it might be
easiest to delete everything and check out a clean source tree);
  * no left over output files or temporary files from previous build
attempts, such as TOOLDIR, RELEASEDIR, DESTDIR, or obj dirs;
  * no /etc/mk.conf or similar file;
  * no -V options passed to build.sh;
  * no environment variables that are intended to affect the build.

--apb (Alan Barrett)

I thought of cleaning out the entire src tree and redownloading/re-cvs'ing, but 
John Nemeth didn't think that necessary.

This is a USB-stick installation with src tree and pkgsrc tree on FreeBSD 
hard-drive partition, so I want to do the build work on the hard drive.

Src and pkgsrc trees are /BETA1/netbsd-HEAD/usr/src and /BETA1/pkgsrc 
respectively.

This happened because there is a bug in FreeBSD support for Realtek 8111E 
Ethernet on MSI Z77 MPOWER motherboard, but OK with NetBSD-current and NetBSD 
6.1_STABLE, amd64 in both cases.  OpenBSD 5.4 and DragonFlyBSD 3.6.0 share this 
FreeBSD bug; I tested from Live USB sticks.  OK with Linux from SystemRescueCD 
3.6.0 USB-stick install.

NetBSD is the only OS where I can download FreeBSD source, ports and doc trees 
onto UFS2/ffsv2 partition using subversion, built from NetBSD pkgsrc in this 
case.

I need /etc/mk.conf for pkgsrc though it apparently plays no role in system 
builds.

 Is this problem repeatable, and does it also appear with -j1?

--apb (Alan Barrett)

I never set -j1, though I've omitted this parameter a few times, and it made no 
apparent difference.

FreeBSD advises not using such a parameter on system builds, so I could follow 
this advice for NetBSD too.

Reason for the subject line with mpc, gmp and mpfr was the belief that partial 
update might be screwing the build.

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Patrick Welche 
On Tue, Dec 17, 2013 at 01:16:29PM +, Thomas Mueller wrote:
  A clean build with no special options means at least this:
 
   * clean source tree, with no extra or modified files (it might be
 easiest to delete everything and check out a clean source tree);
   * no left over output files or temporary files from previous build
 attempts, such as TOOLDIR, RELEASEDIR, DESTDIR, or obj dirs;
   * no /etc/mk.conf or similar file;
   * no -V options passed to build.sh;
   * no environment variables that are intended to affect the build.

Good advice!

 I need /etc/mk.conf for pkgsrc though it apparently plays no role in system 
 builds.

/etc/mk.conf is used in system builds - hence the suggestion to try building
without, above.

  Is this problem repeatable, and does it also appear with -j1?
 
 --apb (Alan Barrett)
 
 I never set -j1, though I've omitted this parameter a few times, and it made 
 no apparent difference.

This is odd, as from your previous message:

 === build.sh command:./build.sh -m amd64 -M ../obj.amd64.llvm
 -B nb20131214-llvm -T ../tooldir.amd64.llvm -V MKLLVM=yes -V
 HAVE_LLVM=yes -V MKLIBCXX=yes -U -j 9 distribution kernel=GENERIC

The reason for trying -j1, i.e., a serial build, is again to simplify
the build so that issues of the form object A hadn't finished building
before it was needed by B in the other parallel make can be ruled out.

Cheers,

Patrick

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Alan Barrett 

On Tue, 17 Dec 2013, Thomas Mueller wrote:
I thought of cleaning out the entire src tree and 
redownloading/re-cvs'ing, but John Nemeth didn't think that 
necessary.


If your source tree is clean, then downloading again is not 
necessary.  Given all the problems you have had, I am not 
confident that your source tree is clean.


Instead of telling us what you thought of doing, it would be more 
useful for you to tell us whether your source tree is clean, and 
whether you have removed all temporary files and outputs from 
previous build attempts.


This is a USB-stick installation with src tree and pkgsrc tree 
on FreeBSD hard-drive partition, so I want to do the build work 
on the hard drive.


Src and pkgsrc trees are /BETA1/netbsd-HEAD/usr/src and 
/BETA1/pkgsrc respectively.


Let's do one thing at a time, please.  Either pkgsrc or src, but 
not both.


This happened because there is a bug in FreeBSD support for 
Realtek 8111E Ethernet on MSI Z77 MPOWER motherboard, but OK 
with NetBSD-current and NetBSD 6.1_STABLE, amd64 in both cases. 
OpenBSD 5.4 and DragonFlyBSD 3.6.0 share this FreeBSD bug; I 
tested from Live USB sticks.  OK with Linux from SystemRescueCD 
3.6.0 USB-stick install.


NetBSD is the only OS where I can download FreeBSD source, ports 
and doc trees onto UFS2/ffsv2 partition using subversion, built 
from NetBSD pkgsrc in this case.


I don't see how that's relevant to your build problems.  Please 
keep to one issue at a time.


I need /etc/mk.conf for pkgsrc though it apparently plays no 
role in system builds.


/etc/mk.conf *is* used for system builds.  Since you didn't 
answer the question about whether all the pkgsrc-related stuff is 
protected by .if defined(BSD_PKG_MK), I am not confident that 
your /etc/mk.conf is safe to use in a system build.  So, please 
remove it, or rename it, to ensure that it is not used by a system 
build.



Is this problem repeatable, and does it also appear with -j1?


I never set -j1, though I've omitted this parameter a few times, 
and it made no apparent difference.


When you get questions from people who are trying to help you, the 
people usually think that the answers will help them to understand 
the problem, and that will help them to help you.  If you want 
them to help you, then please answer the questions.  Here they are 
again, with more detail:


Is that unable to rename temporary message the very first 
error?  Since it was a parallel make, with -j9, error messages are 
interspersed with non-error messages from other branches of the 
parallel make.  You might need to go back a lot further than you 
expect, to find the first error message.


Is this problem repeatable?  That is, does the build fail in 
exactly the same way every time?  If you have not tried multiple 
builds, then do so now, and report whether they always fail in 
exactly the same way.


Does the build fail in exactly the same way even with -j1?  If 
you have not tried a -j1 build, then do so now, and report 
whether or it fails in exactly the same way.


FreeBSD advises not using such a parameter on system builds, so 
I could follow this advice for NetBSD too.


There are lots of things you could do.  For example, you could 
pay attention to advice that you receive, and you could answer 
questions about the problems that you experience.


I don't know why I am still trying to help you.

Reason for the subject line with mpc, gmp and mpfr was the 
belief that partial update might be screwing the build.


Is partial update something that you did, or something that you 
think somebody else did?


If partial update means that you have updated only part of your 
source tree, then things are very likely to go wrong.  Don't do 
that unless you are able to deal with any problems yourself.  If 
you want help from others, then you should have a consistent 
source tree, from a date and time when it was working.  If you 
don't know an appropriate date and time, then check the reports at 
http://releng.netbsd.org/.


If you think that somebody with commit access to the NetBSD tree 
performed a partial update, perhaps by forgetting to commit 
something, then please explain in more detail, or just update to 
a source tree from a date and time when it was working.  People 
do make mistakes, but anything that breaks the build on common 
platforms is usually noticed and fixed quickly.


--apb (Alan Barrett)

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Michael van Elst 
a...@cequrux.com (Alan Barrett) writes:

Is that unable to rename temporary message the very first 
error?

Looks like it. I have seen the same thing twice when building amd64
with -j4. It does not repeat, even a subsequent update build succeeds.

To me that's an issue with the parallel make.

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Christos Zoulas 
In article l8qftg$ajf$1...@serpens.de,
Michael van Elst mlel...@serpens.de wrote:
a...@cequrux.com (Alan Barrett) writes:

Is that unable to rename temporary message the very first 
error?

Looks like it. I have seen the same thing twice when building amd64
with -j4. It does not repeat, even a subsequent update build succeeds.

To me that's an issue with the parallel make.

There is a race in the .BEGIN targets that create directories/symlinks.
I have not looked into it yet.

christos

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Rhialto 
On Tue 17 Dec 2013 at 21:32:32 +, Michael van Elst wrote:
 To me that's an issue with the parallel make.

I think I have reported a mysterious problem in parallel makes myself at
some point, that other people apparenly don't see. So these kinds of
things are rather tricky to debug.
Ah here it is: http://marc.info/?l=netbsd-current-usersm=130445236809042
I haven't tried recently if the proplem persists; since then I build
without -j.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'



pgpAsBzm2U5qx.pgp
Description: PGP signature

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Christos Zoulas 
In article 201312180036.rbi0au7d007...@server.cornerstoneservice.ca,
John Nemeth  jnem...@cue.bc.ca wrote:


 -j1 is not the same as leaving out -j completely and can
have different failure modes.  If you want to try a non-parallel
build, it is best to leave out -j completely.

Absolutely, leaving -j out uses the default compat make engine which
processes dependencies using entirely different code paths.

christos

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Thomas Mueller 
 On Dec 17,  1:16pm, Thomas Mueller wrote:
}
 }  A clean build with no special options means at least this:
}
 }   * clean source tree, with no extra or modified files (it might be
 } easiest to delete everything and check out a clean source tree);
 }   * no left over output files or temporary files from previous build
 } attempts, such as TOOLDIR, RELEASEDIR, DESTDIR, or obj dirs;
 }   * no /etc/mk.conf or similar file;
 }   * no -V options passed to build.sh;
 }   * no environment variables that are intended to affect the build.
}
 } --apb (Alan Barrett)
}
 } I thought of cleaning out the entire src tree and
 } redownloading/re-cvs'ing, but John Nemeth didn't think that necessary.

  That's not what I said/meant.  I said that when people say
 that tools should be cleaned out they mean TOOLDIR.

  However, if your src tree is corrupt in some manner, it can
 cause build failures.  This is a seperate issue from where tools
 needs to be cleaned out.  Given all the build problems that you've
 been having, deleting and redownloading src is likely to be a good
 idea.  It may not help, but it won't hurt, and it eliminates one
 potential problem area.

 } I need /etc/mk.conf for pkgsrc though it apparently plays no role
 } in system builds.

  As others have said, this is not true.  /etc/mk.conf will affect
 builds.  You should adjust your file to look like:

 #if BSD_PKG_MK
...
 pkgsrc stuff
...
 #endif

 } I never set -j1, though I've omitted this parameter a few times,
 } and it made no apparent difference.
}
 } FreeBSD advises not using such a parameter on system builds, so
 } I could follow this advice for NetBSD too.

  Who cares what they advise.  You're not building FreeBSD,
 you're building NetBSD, and using a NetBSD host to do so.  FreeBSD
 building instructions/advice is not applicable in any way, shape,
 or form.

 } Reason for the subject line with mpc, gmp and mpfr was the belief
 } that partial update might be screwing the build.

  This suggestion has been proven false by the fact that many
 people have no problem building the system (I built it myself a
 few days ago).  There are official builds happening regularly on
 the automated build cluster.

Thanks to you and others, too much to quote, for suggestions.

I could and probably will omit -j parameter with build.sh, and might try
to build for i386.

I just looked in NetBSD's /etc/mk.conf and found the lines
#if BSD_PKG_MK 
#endif
with pkgsrc stuff in between, so those lines are still there.

But in the logs for daily builds on 
http://releng.netbsd.org/cgi-bin/builds.cgi

I notice -j11, which would look to be too much for my CPU.

Many successful builds, but netbsd-5-2 just had 3 ok, 52 failed, so even the
stable branches don't succeed all the time.

It is possible not only that my src tree might be corrupted but also that
my NetBSD installation on USB stick might be corrupted.

I could define a separate /etc/makenetbsd.conf with changeable options to
be used some of the time.

I must bear in mind that FreeBSD is much stabler than NetBSD on my hardware.
Only thing I can think of that works better in NetBSD than FreeBSD on 
MSI Z77 MPOWER motherboard is re(4) Ethernet: also good in Linux 
(System Rescue CD 3.6.0) but fails to connect with OpenBSD 5.4 and
DragonFlyBSD 3.6.0, which are their latest releases.

I originally built NetBSD system from FreeBSD 9.1_STABLE (md64 now at 9.2) using
base gcc 4.2.1, the latest gcc before switch to GPL3 license.  I succeeded
better than half the time for i386 but rarely for building NetBSD amd64.

Now I think I could use a newer gcc from FreeBSD ports if I choose or need to
cross-compile NetBSD from FreeBSD.

I always use build.sh to build NetBSD system, have never used make directly for
that purpose.

I could also try to build from a USB-stick installation of NetBSD 6.1_STABLE,
amd64 or i386.

Now busy with FreeBSD and some other things, there might be some delay getting 
back to NetBSD.

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Alan Barrett 

On Wed, 18 Dec 2013, Thomas Mueller wrote:

[56 quoted lines]


Please trim your quotes!  Quote enough to remind readers of the 
context, and quote anything that you respond to directly, but 
there's no need to quote the entire message.


I could and probably will omit -j parameter with build.sh, and 
might try to build for i386.


Christos already reported that there's a known bug in the .BEGIN 
target in a Makefile that might cause the problem you see.



I just looked in NetBSD's /etc/mk.conf and found the lines
#if BSD_PKG_MK
#endif
with pkgsrc stuff in between, so those lines are still there.


It should be .if and .endif, not #if and #endif, like this:

.if defined(BSD_PKG_MK)
pkgsrc stuff goes here
.endif

But in the logs for daily builds on 
http://releng.netbsd.org/cgi-bin/builds.cgi


I notice -j11, which would look to be too much for my CPU.


I suggest starting with a -j value equal to the number of CPUs, 
and then you can increase or decrease it as appropriate.  Using a 
-j value much larger than the number of CPUs is unlikely to be 
useful.  For example, if you have 4 CPUs, then try -j4, and you 
might later decide to decrease it to -j3 or increase it to -j5 or 
-j6, but it's probably not useful to try anything higher than -j8.


Many successful builds, but netbsd-5-2 just had 3 ok, 52 failed, 
so even the stable branches don't succeed all the time.


Yes, there are sometimes build breaks in the stable branches.

It is possible not only that my src tree might be corrupted 
but also that my NetBSD installation on USB stick might be 
corrupted.


It's possible, but then I would expect more obvious symptoms.

I could define a separate /etc/makenetbsd.conf with changeable 
options to be used some of the time.


Yes, and you can pass -V MAKECONF=/etc/makenetbsd.conf to 
build.sh to make it use that file instead of /etc/make.conf.


I must bear in mind that FreeBSD is much stabler than NetBSD on 
my hardware.


Please report crashes.  I don't know whether there's a document 
on how to do that, but you can use the send-pr(1) program, and 
include the relevant kernel messages (the green text you might see 
on the console), and any extra information you are able to gather 
from the kernel debugger (an abbreviated version of the output 
from ddb's bt command is often useful).


Now I think I could use a newer gcc from FreeBSD ports if I 
choose or need to cross-compile NetBSD from FreeBSD.


I always use build.sh to build NetBSD system, have never used 
make directly for that purpose.


Please just use build.sh.  It should allow building NetBSD from 
FreeBSD, or building NetBSD from another version of NetBSD, or 
many other things.


It is theoretically possible to use a different compiler, but 
that's usually done only by people who are porting NetBSD to a new 
platform, porting a new compiler to NetBSD, or something similarly 
tricky.


--apb (Alan Barrett)

Re: NetBSD-HEAD amd64 refuses to build

2013-12-17 Thread Aleksej Saushev 
Alan Barrett a...@cequrux.com writes:

 On Wed, 18 Dec 2013, Thomas Mueller wrote:
 I just looked in NetBSD's /etc/mk.conf and found the lines
 #if BSD_PKG_MK
 #endif
 with pkgsrc stuff in between, so those lines are still there.

 It should be .if and .endif, not #if and #endif, like this:

 .if defined(BSD_PKG_MK)
 pkgsrc stuff goes here
 .endif

This is documented in The pkgsrc Guide at least. It would be nice
if someone could revisit it and proof-read it. Preferably someone
else (i.e. not me). At least impressions and suggestions would be
welcome.

 I must bear in mind that FreeBSD is much stabler than NetBSD
 on my hardware.

 Please report crashes.  I don't know whether there's a document
 on how to do that, but you can use the send-pr(1) program, and
 include the relevant kernel messages (the green text you might
 see on the console), and any extra information you are able to
 gather from the kernel debugger (an abbreviated version of the
 output from ddb's bt command is often useful).

http://wiki.netbsd.org/panic


-- 
HE CE3OH...

NetBSD-HEAD amd64 refuses to build

2013-12-14 Thread mueller6724 
I tried to build this time with 
MKLLVM=yes
HAVE_LLVM=yes
MKLIBCXX=yes
and again failed.


=== build.sh command:./build.sh -m amd64 -M ../obj.amd64.llvm -B 
nb20131214-llvm -T ../tooldir.amd64.llvm -V MKLLVM=yes -V HAVE_LLVM=yes -V 
MKLIBCXX=yes -U -j 9 distribution kernel=GENERIC
=== build.sh started:Sat Dec 14 08:58:39 UTC 2013
=== NetBSD version:  6.99.28
=== MACHINE: amd64
=== MACHINE_ARCH:x86_64
=== Build platform:  NetBSD 6.99.23 amd64
=== HOST_SH: /bin/sh
=== No $TOOLDIR/bin/nbmake, needs building.
=== Bootstrapping nbmake
checking for sh... /bin/sh

Last 63 lines of failed log follow, and I am at the computer where the failed 
builds take place, away from the rest of the message thread:

#   compile  lib/netmask.o
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-clang -O2 
-std=gnu99  -Wno-sign-compare -Wno-pointer-sign  -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-sign-compare  -Wa,--fatal-warnings 
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra 
-Wno-unused-parameter -Wno-sign-compare -Wsign-compare -Wformat=2  
-Wno-error=format-nonliteral-Wpointer-sign -Wmissing-noreturn  -Werror 
--sysroot=/BETA1/netbsd-HEAD/usr/src/../obj.amd64.llvm/BETA1/netbsd-HEAD/usr/src/destdir.amd64
 -DCONFIG_ISCSI_DEBUG -DHAVE_CONFIG_H 
-I/BETA1/netbsd-HEAD/usr/src/external/bsd/iscsi/lib/../dist/include -pthread  
-c
/BETA1/netbsd-HEAD/usr/src/external/bsd/iscsi/lib/../dist/src/lib/netmask.c -o 
netmask.o
--- disk.o ---
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-objcopy -x 
disk.o
--- initiator.po ---
error: unable to rename temporary 'initiator.po-fe88e164' to output file 
'initiator.po': 'No such file or directory'
1 error generated.
--- target.po ---
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-objcopy -X 
target.po
--- initiator.po ---
*** [initiator.po] Error code 1
nbmake[6]: stopped in /BETA1/netbsd-HEAD/usr/src/external/bsd/iscsi/lib
--- util.pico ---
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-objcopy -x 
util.pico
--- md5hl.o ---
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-objcopy -x 
md5hl.o
--- target.pico ---
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-objcopy -x 
target.pico
--- netmask.o ---
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-objcopy -x 
netmask.o
--- util.po ---
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-objcopy -X 
util.po
--- initiator.o ---
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/x86_64--netbsd-objcopy -x 
initiator.o
1 error
nbmake[6]: stopped in /BETA1/netbsd-HEAD/usr/src/external/bsd/iscsi/lib
*** [dependall] Error code 2
nbmake[5]: stopped in /BETA1/netbsd-HEAD/usr/src/external/bsd/iscsi/lib
1 error
nbmake[5]: stopped in /BETA1/netbsd-HEAD/usr/src/external/bsd/iscsi/lib
*** Failed target:  dependall-../external/bsd/iscsi/lib
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift; 
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=lib/; 
real=/BETA1/netbsd-HEAD/usr/src/lib ;; *) this=lib/${dir}/; 
real=/BETA1/netbsd-HEAD/usr/src/lib/${dir} ;; esac; show=${this:-.}; echo 
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}  
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64.llvm/bin/nbmake _THISDIR_=${this} 
$@ ${target}; }; _makedirtarget ../external/bsd/iscsi/lib dependall
*** Error code 2

Stop.
nbmake[4]: stopped in /BETA1/netbsd-HEAD/usr/src/lib
*** [build_install] Error code 1

nbmake[3]: stopped in /BETA1/netbsd-HEAD/usr/src/lib
1 error

nbmake[3]: stopped in /BETA1/netbsd-HEAD/usr/src/lib
*** [do-lib] Error code 2

nbmake[2]: stopped in /BETA1/netbsd-HEAD/usr/src
1 error

nbmake[2]: stopped in /BETA1/netbsd-HEAD/usr/src
*** [build] Error code 2

nbmake[1]: stopped in /BETA1/netbsd-HEAD/usr/src
1 error

nbmake[1]: stopped in /BETA1/netbsd-HEAD/usr/src
*** [distribution] Error code 2

nbmake: stopped in /BETA1/netbsd-HEAD/usr/src
1 error

nbmake: stopped in /BETA1/netbsd-HEAD/usr/src

ERROR: Failed to make distribution
*** BUILD ABORTED ***

Re: NetBSD-HEAD amd64 refuses to build

2013-12-13 Thread David Holland 
On Mon, Dec 09, 2013 at 08:20:28AM +, mueller6...@bellsouth.net wrote:
  I keep failing in recent days to update NetBSD-HEAD amd64 from source,
  
  Previous recent attempts resulted in internal compiler error.
  
  This time, [...]

I still don't understand what you're trying to do, or why you're
apparently surprised it doesn't work.

-- 
David A. Holland
dholl...@netbsd.org

Re: NetBSD-HEAD amd64 refuses to build

2013-12-13 Thread Martin Husemann 
Since -current had some hard times in the last few weeks, and maybe
not everyone is aware of this site:

  http://releng.netbsd.org/cgi-bin/builds.cgi

shows the status of the last autobuilds. We already had one working
-current (HEAD) build this week, yay!

As you can see there, the stable branches rarely fail to build. When
they do, it either is a spurious problem of the autobuild system (e.g.
running out of disk space), or a broken pullup, that will usualy be
fixed within a few hours.

If you try to build one of the stable branches locally (from clean
source trees and empty obj dir), and fail, this either is a clear
failure in the tools phase (e.g. when you build on some host system
that hasn't been tested lately), in this case: file a PR.
Or: you are passing some strange options to build.sh, e.g. an inconsistent
or not supported mixture of MK...=YES/NO flags. You should not fiddle with
those flags normally, unless you clearly understand all implications and
are willing to fix the fallout.

Martin

Re: NetBSD-HEAD amd64 refuses to build

2013-12-13 Thread Rhialto 
On Fri 13 Dec 2013 at 09:55:54 +0100, Martin Husemann wrote:
 Since -current had some hard times in the last few weeks, and maybe
 not everyone is aware of this site:
 
   http://releng.netbsd.org/cgi-bin/builds.cgi
 
 shows the status of the last autobuilds. We already had one working
 -current (HEAD) build this week, yay!

Note I'm not the original poster of this thread but I did report a
~similar problem.

I just looked at the amd64 build, at
http://releng.netbsd.org/builds/HEAD/201312072350Z/amd64.build, and the
string libunwind doesn't occur in the whole output.

The thing I was trying to do differently than before was to build (but
not use) llvm. I thought I would not change too many things at once.
But perhaps just building llvm triggers the building of libunwind, which
for whatever reason[1] does not work if it is built with gcc.

[1] such as incorrect compiler flags

Next thing I'll try is adding -V HAVE_LLVM=yes -V MKLIBCXX=yes and see
if it works for me then.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'



pgpNpVbjp8TUz.pgp
Description: PGP signature

Re: NetBSD-HEAD amd64 refuses to build

2013-12-13 Thread Rhialto 
On Fri 13 Dec 2013 at 12:08:02 +0100, Rhialto wrote:
 Next thing I'll try is adding -V HAVE_LLVM=yes -V MKLIBCXX=yes and see
 if it works for me then.

I removed all obj directories except for the tools (to save some time),
so the build is now already past the creation of libc/libunwind.d.

So it seems that currently, if you want to build llvm, you need to use
it for the build as well.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


pgps7_Yh37hRk.pgp
Description: PGP signature

Re: NetBSD-HEAD amd64 refuses to build

2013-12-13 Thread Thomas Mueller 
 Since -current had some hard times in the last few weeks, and maybe
 not everyone is aware of this site:

   http://releng.netbsd.org/cgi-bin/builds.cgi

 shows the status of the last autobuilds. We already had one working
 -current (HEAD) build this week, yay!

 As you can see there, the stable branches rarely fail to build. When
 they do, it either is a spurious problem of the autobuild system (e.g.
 running out of disk space), or a broken pullup, that will usualy be
 fixed within a few hours.

 If you try to build one of the stable branches locally (from clean
 source trees and empty obj dir), and fail, this either is a clear
 failure in the tools phase (e.g. when you build on some host system
 that hasn't been tested lately), in this case: file a PR.
 Or: you are passing some strange options to build.sh, e.g. an inconsistent
 or not supported mixture of MK...=YES/NO flags. You should not fiddle with
 those flags normally, unless you clearly understand all implications and
 are willing to fix the fallout.

 Martin

 I still don't understand what you're trying to do, or why you're
 apparently surprised it doesn't work.

--
 David A. Holland
 dholl...@netbsd.org

I've been following that website consistently for many months.

Most of the time, even recently, HEAD built successfully for amd64 and i386.

I keep getting Internal compiler error, segmentation fault when using base gcc,
without any strange or fancy stuff in build.sh command.

Possibly with gcc not being upgraded while mpc, mpfr and gmp have been (?), 
something is out of sync?  But I was able to build lang/clang and also gcc48
and gcc-aux from pkgsrc, so I thought maybe not rebuild base gcc.

But there was another suggestion to put -std=c++0x or -std=gnu++0x , and I 
wanted to know where to do that for build.sh .

I updated NetBSD 6.1_STABLE on other computer, and for the first time, was
successful booting on MSI Z77 MPOWER motherboard.  Maybe the result of five
months of improvements?

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-13 Thread Chavdar Ivanov 
I build amd64 and i386 -current overnight using
pkgsrc/sysutils/sysbuild via a cron job:
...
$ crontab -l
# $NetBSD: crontab,v 1.1 2012/07/25 12:20:08 jmmv Exp $
# crontab(5) file for the unprivileged sysbuild user.

PATH=/usr/pkg/bin:/usr/pkg/sbin:/usr/bin:/usr/sbin:/bin:/sbin
SHELL=/bin/sh

# Cheatsheet: minute hour day-of-month month day-of-week(0,7=Sun)
@daily /usr/pkg/bin/sysbuild4cron -l ${HOME}/log -- build
...

Lately it breaks regularly, sometimes without any error message - in
the morning the log ends halfway through, there are no processes
running; on the other hand sometimes I get stuff like this night:

...
#   compile  huntd/expl.o
/home/sysbuild/Sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -O2
-std=gnu99  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpoi
nter-arith -Wno-sign-compare  -Wno-traditional  -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings
 -Wextra -Wno-unused-parameter -Wno-sign-compare
-Wold-style-definition -Wsign-compare -Wformat=2
-Wno-format-zero-length  -We
rror -DRANDOM -DREFLECT -DMONITOR -DOOZE -DFLY -DVOLCANO -DBOOTS
-DOTTO -DINTERNET -DLOG -DHUNTD=\/usr/games/huntd\ --sys
root=/home/sysbuild/Sysbuild/amd64/destdir  -c
/home/sysbuild/src/games/hunt/huntd/expl.c
sh: Cannot vfork
*** [expl.o] Error code 2
...


Looks like some limits have been changed recently - if I run
interactively as the same sysbuild user, it completes without any
problem (as it did yesterday afternoon).

(the first system I tend to upgrade after successful build is the
build host itseld, so ATM it is running:

[log] uname -a
NetBSD support6.delcam.local 6.99.28 NetBSD 6.99.28 (MINE) #37: Tue
Dec 10 16:02:16 GMT 2013
root@support6.delcam.local:/root/a64/compile/MINE amd64

(MINE is XEN3_DOMU with a single line change - the root is on xbd1a
(don't ask why).

I'll try overnight to double the memory to see if it will make difference.

Chavdar




On 13 December 2013 12:30, Thomas Mueller mueller6...@bellsouth.net wrote:
 Since -current had some hard times in the last few weeks, and maybe
 not everyone is aware of this site:

   http://releng.netbsd.org/cgi-bin/builds.cgi

 shows the status of the last autobuilds. We already had one working
 -current (HEAD) build this week, yay!

 As you can see there, the stable branches rarely fail to build. When
 they do, it either is a spurious problem of the autobuild system (e.g.
 running out of disk space), or a broken pullup, that will usualy be
 fixed within a few hours.

 If you try to build one of the stable branches locally (from clean
 source trees and empty obj dir), and fail, this either is a clear
 failure in the tools phase (e.g. when you build on some host system
 that hasn't been tested lately), in this case: file a PR.
 Or: you are passing some strange options to build.sh, e.g. an inconsistent
 or not supported mixture of MK...=YES/NO flags. You should not fiddle with
 those flags normally, unless you clearly understand all implications and
 are willing to fix the fallout.

 Martin

 I still don't understand what you're trying to do, or why you're
 apparently surprised it doesn't work.

 --
 David A. Holland
 dholl...@netbsd.org

 I've been following that website consistently for many months.

 Most of the time, even recently, HEAD built successfully for amd64 and i386.

 I keep getting Internal compiler error, segmentation fault when using base 
 gcc,
 without any strange or fancy stuff in build.sh command.

 Possibly with gcc not being upgraded while mpc, mpfr and gmp have been (?),
 something is out of sync?  But I was able to build lang/clang and also gcc48
 and gcc-aux from pkgsrc, so I thought maybe not rebuild base gcc.

 But there was another suggestion to put -std=c++0x or -std=gnu++0x , and I
 wanted to know where to do that for build.sh .

 I updated NetBSD 6.1_STABLE on other computer, and for the first time, was
 successful booting on MSI Z77 MPOWER motherboard.  Maybe the result of five
 months of improvements?

 Tom




--

Re: NetBSD-HEAD amd64 refuses to build

2013-12-12 Thread Thomas Mueller 
 On Mon, Dec 09, 2013 at 08:19:53AM +, mueller6...@bellsouth.net wrote:
  This time, using build.sh as always, I added -V MKLLVM=yes and 
  HAVE_LLVM=yes to command line:

 For amd64, clang defaults to libc++, so you want -V MKLIBCXX=yes as
 well.

 Joerg

Wiki didn't say that, so I didn't know: something new to try.

I could also try to build NetBSD-current i386.

That would be a fresh install, since NetBSD-current i386 didn't like the 16 GB 
USB stick it was on, and I dd'ed OpenBSD 5.4 Live USB over it.

When booting that USB stick with NetBSD-current -386, I kept getting green 
trouble messages, also /etc/rc.conf was messed up a few times.

Do I also need to set -std=c++0x and/or -std=gnu++0x as well, and if so, how 
and where?

I was successful building lang/clang in pkgsrc, maybe use that?

Is there an incompatibility betwen mpc, gmp, mpfr and the not-yet updated base 
gcc?

Could I tell build.sh to not build these since I have the pkgsrc versions?

Tom

Re: NetBSD-HEAD amd64 refuses to build

2013-12-11 Thread Joerg Sonnenberger 
On Mon, Dec 09, 2013 at 08:19:53AM +, mueller6...@bellsouth.net wrote:
 This time, using build.sh as always, I added -V MKLLVM=yes and HAVE_LLVM=yes 
 to command line:

For amd64, clang defaults to libc++, so you want -V MKLIBCXX=yes as
well.

Joerg

NetBSD-HEAD amd64 refuses to build

2013-12-09 Thread mueller6724 
I keep failing in recent days to update NetBSD-HEAD amd64 from source,

Previous recent attempts resulted in internal compiler error.

This time, using build.sh as always, I added -V MKLLVM=yes and HAVE_LLVM=yes to 
command line:


=== build.sh command:./build.sh -m amd64 -M ../obj.amd64 -B nb20131209 -T 
../tooldir.amd64 -V MKLLVM=yes -V HAVE_LLVM=yes -U -j 9 distribution 
kernel=GENERIC
=== build.sh started:Mon Dec  9 05:17:03 UTC 2013
=== NetBSD version:  6.99.28
=== MACHINE: amd64
=== MACHINE_ARCH:x86_64
=== Build platform:  NetBSD 6.99.23 amd64
=== HOST_SH: /bin/sh
=== MAKECONF file:   /etc/mk.conf
=== TOOLDIR path:/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64
=== DESTDIR path:
/BETA1/netbsd-HEAD/usr/src/../obj.amd64/BETA1/netbsd-HEAD/usr/src/destdir.amd64

I was subsequently successful building lang/clang from pkgsrc so I don't have 
to rebuild clang every time with system source.

Then I could use HOST_CC=/usr/pkg/bin/clang 
and HOST_CXX=/usr/pkg/bin/clang++

Was there a missing file (cassert) as the following final part of the log shows?

I could wait several days or longer and try again, perhaps from NetBSD 
6.1_STABLE amd64, if that boots, or sojourn to FreeBSD now that I got my Hiro 
USB wireless adapter to work (chip RTL8191SU, driver rsu).

I see that on http://nyftp/netbsd.org/cgi-bin/builds.cgi, the host machine is
NetBSD-6.0.1-PATCH amd64.  That would be the reason to use my USB-stick 
installation of 6.1_STABLE amd64.

Last part of log file follows, and I am seeing if I can send this from 
NetBSD-6.99.23-amd64 with msmtp, recently built from pkgsrc:

#create  libc/localeconv.d
CC=/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64/bin/x86_64--netbsd-clang 
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64/bin/nbmkdep -f localeconv.d.tmp  -- 
 
--sysroot=/BETA1/netbsd-HEAD/usr/src/../obj.amd64/BETA1/netbsd-HEAD/usr/src/destdir.amd64
 -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -D_DIAGNOSTIC -DMLIBDIR=\\ 
-DHESIOD -DINET6 -DNLS -DYP -I/BETA1/netbsd-HEAD/usr/src/lib/libc/include 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc -I/BETA1/netbsd-HEAD/usr/src/sys 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/../locale 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/stdlib 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/../stdlib -D__BUILD_LEGACY 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/quad 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/string 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/arch/x86_64/string 
-D__DBINTERFACE_PRIVATE -I/BETA1/netbsd-HEAD/usr/src/libexec/ld.elf_so 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/dlfcn -I/BETA1/netbsd-
 HEAD/usr/src/lib/libc/gdtoa -I/BETA1/netbsd-HEAD/usr/src/lib/libc/locale 
-DNO_FENV_H -I/BETA1/netbsd-HEAD/usr/src/lib/libc/arch/x86_64/gdtoa -DWITH_RUNE 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES -DUSE_POLL 
-DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT  -D_FORTIFY_SOURCE=2 
/BETA1/netbsd-HEAD/usr/src/lib/libc/locale/localeconv.c   mv localeconv.d.tmp 
localeconv.d
--- localtime.d ---
--- libunwind.d ---
In file included from 
/BETA1/netbsd-HEAD/usr/src/sys/lib/libunwind/libunwind.cxx:16:
In file included from 
/BETA1/netbsd-HEAD/usr/src/sys/lib/libunwind/UnwindCursor.hpp:19:
/BETA1/netbsd-HEAD/usr/src/sys/lib/libunwind/AddressSpace.hpp:17:10: fatal 
error: 'cassert' file not found
#include cassert
 ^
--- lockf.d ---
--- localtime.d ---
#create  libc/localtime.d
CC=/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64/bin/x86_64--netbsd-clang 
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64/bin/nbmkdep -f localtime.d.tmp  --  

--sysroot=/BETA1/netbsd-HEAD/usr/src/../obj.amd64/BETA1/netbsd-HEAD/usr/src/destdir.amd64
 -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -D_DIAGNOSTIC -DMLIBDIR=\\ 
-DHESIOD -DINET6 -DNLS -DYP -I/BETA1/netbsd-HEAD/usr/src/lib/libc/include 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc -I/BETA1/netbsd-HEAD/usr/src/sys 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/../locale 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/stdlib 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/../stdlib -D__BUILD_LEGACY 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/quad 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/string 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/arch/x86_64/string 
-D__DBINTERFACE_PRIVATE -I/BETA1/netbsd-HEAD/usr/src/libexec/ld.elf_so 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/dlfcn -I/BETA1/netbsd-H
 EAD/usr/src/lib/libc/gdtoa -I/BETA1/netbsd-HEAD/usr/src/lib/libc/locale 
-DNO_FENV_H -I/BETA1/netbsd-HEAD/usr/src/lib/libc/arch/x86_64/gdtoa -DWITH_RUNE 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES -DUSE_POLL 
-DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT  -D_FORTIFY_SOURCE=2 
/BETA1/netbsd-HEAD/usr/src/lib/libc/time/localtime.c   mv localtime.d.tmp 
localtime.d
--- lockf.d ---
#create  libc/lockf.d

NetBSD-HEAD amd64 refuses to build

2013-12-09 Thread mueller6724 
I keep failing in recent days to update NetBSD-HEAD amd64 from source,

Previous recent attempts resulted in internal compiler error.

This time, using build.sh as always, I added -V MKLLVM=yes and HAVE_LLVM=yes to 
command line:


=== build.sh command:./build.sh -m amd64 -M ../obj.amd64 -B nb20131209 -T 
../tooldir.amd64 -V MKLLVM=yes -V HAVE_LLVM=yes -U -j 9 distribution 
kernel=GENERIC
=== build.sh started:Mon Dec  9 05:17:03 UTC 2013
=== NetBSD version:  6.99.28
=== MACHINE: amd64
=== MACHINE_ARCH:x86_64
=== Build platform:  NetBSD 6.99.23 amd64
=== HOST_SH: /bin/sh
=== MAKECONF file:   /etc/mk.conf
=== TOOLDIR path:/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64
=== DESTDIR path:
/BETA1/netbsd-HEAD/usr/src/../obj.amd64/BETA1/netbsd-HEAD/usr/src/destdir.amd64

I was subsequently successful building lang/clang from pkgsrc so I don't have 
to rebuild clang every time with system source.

Then I could use HOST_CC=/usr/pkg/bin/clang 
and HOST_CXX=/usr/pkg/bin/clang++

Was there a missing file (cassert) as the following final part of the log shows?

I could wait several days or longer and try again, perhaps from NetBSD 
6.1_STABLE amd64, if that boots, or sojourn to FreeBSD now that I got my Hiro 
USB wireless adapter to work (chip RTL8191SU, driver rsu).

I see that on http://nyftp/netbsd.org/cgi-bin/builds.cgi, the host machine is
NetBSD-6.0.1-PATCH amd64.  That would be the reason to use my USB-stick 
installation of 6.1_STABLE amd64.

Last part of log file follows, and I am seeing if I can send this from 
NetBSD-6.99.23-amd64 with msmtp, recently built from pkgsrc:

#create  libc/localeconv.d
CC=/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64/bin/x86_64--netbsd-clang 
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64/bin/nbmkdep -f localeconv.d.tmp  -- 
 
--sysroot=/BETA1/netbsd-HEAD/usr/src/../obj.amd64/BETA1/netbsd-HEAD/usr/src/destdir.amd64
 -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -D_DIAGNOSTIC -DMLIBDIR=\\ 
-DHESIOD -DINET6 -DNLS -DYP -I/BETA1/netbsd-HEAD/usr/src/lib/libc/include 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc -I/BETA1/netbsd-HEAD/usr/src/sys 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/../locale 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/stdlib 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/../stdlib -D__BUILD_LEGACY 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/quad 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/string 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/arch/x86_64/string 
-D__DBINTERFACE_PRIVATE -I/BETA1/netbsd-HEAD/usr/src/libexec/ld.elf_so 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/dlfcn -I/BETA1/netbsd-
 HEAD/usr/src/lib/libc/gdtoa -I/BETA1/netbsd-HEAD/usr/src/lib/libc/locale 
-DNO_FENV_H -I/BETA1/netbsd-HEAD/usr/src/lib/libc/arch/x86_64/gdtoa -DWITH_RUNE 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES -DUSE_POLL 
-DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT  -D_FORTIFY_SOURCE=2 
/BETA1/netbsd-HEAD/usr/src/lib/libc/locale/localeconv.c   mv localeconv.d.tmp 
localeconv.d
--- localtime.d ---
--- libunwind.d ---
In file included from 
/BETA1/netbsd-HEAD/usr/src/sys/lib/libunwind/libunwind.cxx:16:
In file included from 
/BETA1/netbsd-HEAD/usr/src/sys/lib/libunwind/UnwindCursor.hpp:19:
/BETA1/netbsd-HEAD/usr/src/sys/lib/libunwind/AddressSpace.hpp:17:10: fatal 
error: 'cassert' file not found
#include cassert
 ^
--- lockf.d ---
--- localtime.d ---
#create  libc/localtime.d
CC=/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64/bin/x86_64--netbsd-clang 
/BETA1/netbsd-HEAD/usr/src/../tooldir.amd64/bin/nbmkdep -f localtime.d.tmp  --  

--sysroot=/BETA1/netbsd-HEAD/usr/src/../obj.amd64/BETA1/netbsd-HEAD/usr/src/destdir.amd64
 -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -D_DIAGNOSTIC -DMLIBDIR=\\ 
-DHESIOD -DINET6 -DNLS -DYP -I/BETA1/netbsd-HEAD/usr/src/lib/libc/include 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc -I/BETA1/netbsd-HEAD/usr/src/sys 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/../locale 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/stdlib 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/compat/../stdlib -D__BUILD_LEGACY 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/quad 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/string 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/../../common/lib/libc/arch/x86_64/string 
-D__DBINTERFACE_PRIVATE -I/BETA1/netbsd-HEAD/usr/src/libexec/ld.elf_so 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc/dlfcn -I/BETA1/netbsd-H
 EAD/usr/src/lib/libc/gdtoa -I/BETA1/netbsd-HEAD/usr/src/lib/libc/locale 
-DNO_FENV_H -I/BETA1/netbsd-HEAD/usr/src/lib/libc/arch/x86_64/gdtoa -DWITH_RUNE 
-I/BETA1/netbsd-HEAD/usr/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES -DUSE_POLL 
-DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT  -D_FORTIFY_SOURCE=2 
/BETA1/netbsd-HEAD/usr/src/lib/libc/time/localtime.c   mv localtime.d.tmp 
localtime.d
--- lockf.d ---
#create  libc/lockf.d