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
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
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,
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
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
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
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
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
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
| 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
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
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,
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
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
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.
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
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
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,
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
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,
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
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
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
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
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
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
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
#
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,
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
29 matches
Mail list logo
