Re: NetBSD-HEAD amd64 refuses to build
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
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
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
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
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
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
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
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
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
| 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
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
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
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
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
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
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
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
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
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
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
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...
Re: NetBSD-HEAD amd64 refuses to build
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
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
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
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
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
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
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
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