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
On Tue, 17 Dec 2013, David Holland wrote:
On Sun, Dec 15, 2013 at 03:13:34PM -0600, John D. Baker wrote:
Core was generated by 'progname'.
Program terminated with signal 11, Segmentation fault.
#0 0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x in _ftext ()
#2
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,
Updating src tree:
P src/bin/chmod/chmod.1
P src/bin/cp/cp.1
P src/distrib/sets/lists/man/mi
P src/distrib/sets/lists/modules/md.evbppc
P src/distrib/sets/lists/modules/mi
P src/distrib/sets/lists/xdebug/md.hp300
P src/external/bsd/mdocml/dist/mdoc_argv.c
P src/sbin/chown/chgrp.1
P
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
13 matches
Mail list logo
