FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Mark Millard]

Summary: RAM+(peak swap) was about 26 GiBytes.
 Also: about 118 GiByte /usr/obj/. . ./llvm40/ area.
 (2 processors, 2 cores each, all in use;
  WITH_DEBUG= used)

The peak usage times were when the 4 cores were
each busy running ld at the same time.

[So far as I know FreeBSD does not report peak swap usage
"since boot". So I do not have a cross check on if I missed
seeing a higher peak then I report in the details below.]

What all this note spans as part of the build:

# more /var/db/ports/devel_llvm40/options
# This file is auto-generated by 'make config'.
# Options for llvm40-4.0.0.r4
_OPTIONS_READ=llvm40-4.0.0.r4
_FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
OPTIONS_FILE_SET+=CLANG
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EXTRAS
OPTIONS_FILE_SET+=LIT
OPTIONS_FILE_SET+=LLD
OPTIONS_FILE_SET+=LLDB

The system clang 4.0 was used to do the build. A port
binutils was used (-B${LOCALBASE}/bin/ in CFLAGS,
CXXFLAGS, an CPPFLAGS). The kernel was non-debug generally
but buildworld buildkernel did not have MALLOC_PRODUCTION= .
The llvm40 build did have MALLOC_PRODUCTION= .

# uname -paKU
FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT  r314687M  powerpc powerpc64 
1200023 1200023

Most of what I have access to for FreeBSD does not have a
big enough configuration to do a WITH_DEBUG= build of llvm40
on a machine with 4 cores, all in use.

One type of environment that does is an old PowerMac G5
so-called "Quad Core" that has 16 GiBytes of RAM, 17 GiBytes
of swap, and a 480 GiByte SSD (but extra over provisioned so
it appears even smaller for the file system+swap).

Watching with top the peak swap usage that I saw was
56% of the 17 GiByte --so call it 10 GiBytes or so.

So something like 16 GiBytes RAM + 10 GiBytes swap
and so something like 26 GiByte total.

I used portmaster with -DK. Afterwards the /usr/obj/
sub-area for llvm40 used totaled to a size of:

# du -sg /usr/obj/portswork/usr/ports/devel/llvm40
118 /usr/obj/portswork/usr/ports/devel/llvm40

So around 118 GiBytes of disk space.

Showing the major space usage contributions:

# du -sg /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/* 
/usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/*
. . .
29  /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/bin
. . .
29  /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/lib
. . .
12  /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/tools
. . .
26  
/usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/bin
. . .
24  
/usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/lib
. . .



Side notes that are more system specific:

The timestamps on the script output file indicate that
the build took about 8 hours 24 minutes.

The powerpc64 system used was built with the system clang
4.0 compiler and a port-based binutils. This is despite that
clang 4.0 produces code that has any thrown C++ exceptions
completely non-functional for powerpc64 (program crashes
via signals reporting problems).

===
Mark Millard
markmi at dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildworld error

[Ngie Cooper (yaneurabeya)]

> On Mar 11, 2017, at 18:24, Ngie Cooper (yaneurabeya)  
> wrote:

Hi Roberto,
The sbin/setkey issue should be resolved by r315181. Thank you for the 
report!
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: buildworld error

[Cy Schubert]

In message 
, Roberto Rodriguez Jr writes:
> Hey,
> 
> Even with a fresh checkout of sources ( today 935am EST). Buildworld/kernel
> fail 10 seconds into build.

Can you post output, please?


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildworld error

[Cy Schubert]

In message <1c4e6a09-86ad-4dc7-aa65-336a1643e...@freebsd.org>, Dimitry 
Andric w
rites:
> 
> 
> --Apple-Mail=_41B95E0F-96E1-4E0A-A996-DE3C34E4B13B
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
>   charset=us-ascii
> 
> On 12 Mar 2017, at 02:46, Cy Schubert  wrote:
> > 
> > In message <5cb065b0-5a7d-4a50-a722-8ea579a67...@freebsd.org>, Dimitry
> > Andric w
> > rites:
> >> 
> >> 
> >> --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7
> >> Content-Transfer-Encoding: quoted-printable
> >> Content-Type: text/plain;
> >>charset=us-ascii
> >> 
> >> On 12 Mar 2017, at 01:55, Roberto Rodriguez Jr  =
> >> wrote:
> >>> =20
> >>> Now...
> >>> make buildworld
> >> ...
> >>> In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15:
> >>> In file included from =
> >> /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20:
> >>> In file included from
> >>> /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19:
> >>> In file included from /usr/include/c++/v1/algorithm:634:
> >>> In file included from /usr/include/c++/v1/memory:604:
> >>> /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' =
> >> file not
> >>> found
> >>> #include <__undef___deallocate>
> >>>^
> >> 
> >> Yes, this is because of the bad advice to run "make delete-old" before
> >> you had run "make installworld".  You had an older version of libc++ in
> >> /usr/include/c++, but that still required the __undef___deallocate
> >> header, which has now been deleted by "make delete-old".
> >> 
> >> Your best chance is to build and install libc++ first, if possible, by
> >> doing:
> >> 
> >> cd /usr/src/lib/libc++
> >> make obj
> >> make depend
> >> make
> >> make install
> >> 
> >> Then retry building world.
> > 
> > If this actually fixes it, it (the build) is wrong. You shouldn't have to
> > build and install src in order to build another part of src.
> > 
> > The procedure has always been documented as make installworld first then
> > make delete-old. Failing to do so will on rare occasions bite you when
> > building a port.
> 
> Yes, but in this case Roberto ran "make delete-old" *before* installing
> world, on your advice. That is definitely something that should be
> avoided.

That's not what I was talking about. I should have worded that better, as 
in for next time. People should run make delete-old after the previous 
installworld and prior to the next buildworld. Even so, the contents of the 
current /usr/include should not affect the current buildworld. In practice 
this is still the case. r307800 is a good example of this. I wouldn't be 
surprised there's more of this in src.

> 
> E.g., "make delete-old" should only ever be run with exactly the same
> source tree that your current world was installed from.  And preferably
> right after "make installworld" and updating /etc.

Exactly!


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD-current, panic on UEFI boot after recent changes

[Subbsd]

Hi,

( I apologize if this is a duplicate - first I wrote this as reply-all
on https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064971.html
thread )

After recent changes and fixes (
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065093.html
) I still had problems on host with increased EFI_STAGING_SIZE value.
I have custom FreeBSD distribution which has a sufficiently large
mfsroot which is loaded through UEFI mode.

To solve the problem, it was suggested to increase this variable and
rebuild /sys/boot:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209944

Also, it has to be increased periodically for some reason:

https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=305779=305778=305779

I've try to ask why than threatens to increase this parameter at once
large (or make it dependent on RAM):
https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050142.html
but there are no answer options.

At the moment, on r315141 boot via UEFI is fine with default
EFI_STAGING_SIZE (64)

With EFI_STAGING_SIZE=768 i got panic after recent changes with follow message:

failed to allocate staging area:9
failed to allocate stating area
Failed to start image provided by ZFS (5)

http://pasteboard.co/IvbhU9Ffu.jpg

I believe that there mfsroot may be greater than 64MB soon or later.

Also there are no problems with loading big mfsroot images when MBR
method is used.

PS:  I have ZFS-on-root system. With EFI_STAGING_SIZE=768 I lived with
constant CURRENT svnup/rebuilds for about a year. So I will be glad if
you pay attention to this.

PPS: How to reproduce:

1) EFI_STAGING_SIZE=768 in /etc/make.conf
2) make -C /sys/boot clean
3) make -C /sys/boot
4) make -C /sys/boot install
5) reboot

Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: process killed: text file modification

[Ian Lepore]

On Thu, 2017-03-09 at 21:07 +0100, Gergely Czuczy wrote:
> 
> On 2017. 03. 09. 20:47, Gergely Czuczy wrote:
> > 
> > 
> > 
> > On 2017. 03. 09. 19:44, John Baldwin wrote:
> > > 
> > > On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
> > > > 
> > > > [+freebsd-fs]
> > > > 
> > > > 
> > > > On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
> > > > > 
> > > > > On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > I'm trying to build a few things from ports on an rpi3, the
> > > > > > ports
> > > > > > collection is mounted over NFS from another machine. When
> > > > > > it's trying
> > > > > > to build pkg i'm getting the error message in syslog:
> > > > > > 
> > > > > > rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file
> > > > > > modification
> > > > > > 
> > > > > > The report to pkg@:
> > > > > > https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/
> > > > > > 002048.html 
> > > > > > 
> > > > > > 
> > > > > > In ports-mgmt/pkg's config.log It fails at the following
> > > > > > entry:
> > > > > > configure:3726: checking whether we are cross compiling
> > > > > > configure:3734: cc -o conftest -O2 -pipe  -Wno-error
> > > > > > -fno-strict-aliasing   conftest.c  >&5
> > > > > > configure:3738: $? = 0
> > > > > > configure:3745: ./conftest
> > > > > > configure:3749: $? = 137
> > > > > > configure:3756: error: in 
> > > > > > `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0':
> > > > > > configure:3760: error: cannot run C compiled programs.
> > > > > > If you meant to cross compile, use `--host'.
> > > > > > See `config.log' for more details
> > > > > > 
> > > > > > # uname -a
> > > > > > FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949:
> > > > > > Thu Mar 9
> > > > > > 08:58:46 CET 2017
> > > > > > ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.
> > > > > > aarch64/tank/rpi3/src/sys/AEGIR 
> > > > > > 
> > > > > > arm64
> > > > > So far, a few additions:
> > > > > Time is synced between the NFS server and the client.
> > > > > it's an open() call which is getting the kill, and it's not
> > > > > the file
> > > > > what's being opened, but the process executing it.
> > > > > Here's a simple code that reproduces it:
> > > > > #include 
> > > > > 
> > > > > int main() {
> > > > > 
> > > > >    FILE *f = fopen ("/bar", "w");
> > > > > 
> > > > >    fclose(f);
> > > > >    return 0;
> > > > > }
> > > > > 
> > > > > Conditions to reproduce it:
> > > > >   - The resulting binary must be executed from the nfs mount
> > > > >   - The binary must be built after mounting the NFS share.
> > > > > 
> > > > > I haven't tried building it on a different host, I don't have
> > > > > access
> > > > > to multiple RPis. Also, if I build the binary, umount/remount
> > > > > the NFS
> > > > > mount point, which has the binary, execute it, then it works.
> > > > > 
> > > > > I've also tried this with the raspbsd.org's image, I could
> > > > > reproduce
> > > > > it as well.
> > > > > 
> > > > > Another interesting thing is, when I first booted the RPi up,
> > > > > the NFS
> > > > > server was a 10.2-STABLE, and later got updated to 11-STABLE. 
> > > > > While it
> > > > > was 10.2 I've tried to build some port, and I don't remember
> > > > > having
> > > > > this issue.
> > > > > 
> > > > > So, could someone please help me figure this out and fix it?
> > > > > This
> > > > > stuff should work pretty much.
> > > > > 
> > > > So, this error message comes from here:
> > > > https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio
> > > > .c?revision=314436=markup#l1674 
> > > > 
> > > > 
> > > > It's the NFS_TIMESPEC_COMPARE(>n_mtime, 
> > > > >n_vattr.na_mtime)
> > > > comparision that fails, np should be the NFS node structure,
> > > > from the
> > > > vnode's v_data, and n_vattr is the attribute cache. As I've
> > > > seen these
> > > > two are being updated together, so I don't really see by the
> > > > code why
> > > > they might differ. Could someone please take a look at it, with
> > > > more
> > > > experience in the NFS code? -czg
> > > Can you print out the two mtimes?  I wonder if what's happening
> > > is that
> > > your server uses different granularity (for example just seconds)
> > > than
> > > your client, so on the client we generate a timestamp with a non-
> > > zero
> > > nanoseconds but when the server receives that timestamp it
> > > "truncates"
> > > it.  During open() we forcefully re-fetch the timestamp (for CTO
> > > consistency) and then notice it doesn't match.  For now I would
> > > start
> > > with comparing the timestamps and maybe the
> > > vfs.timestamp_precision
> > > sysctls on client and server (if server is a FreeBSD box).
> > Here are the time values:
> > Mar  9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 + 
> > -3298114786336  >n_vattr.na_mtime: -3298114786616 +
> > -3298114786608
> > Mar  9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed:
> > text 
> > file modification
> > Mar  9 

Re: buildworld error

[Roberto Rodriguez Jr]

Hey,

Even with a fresh checkout of sources ( today 935am EST). Buildworld/kernel
fail 10 seconds into build.

Thanks
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX

[O. Hartmann]

Am Sat, 11 Mar 2017 19:37:32 -0700
Ian Lepore  schrieb:

> On Sun, 2017-03-12 at 13:27 +1100, Lawrence Stewart wrote:
> > Hi Ian,
> > 
> > On 12/03/2017 10:29, Ian Lepore wrote:  
> > > 
> > > On Sun, 2017-03-12 at 10:22 +1100, Lawrence Stewart wrote:  
> > > > 
> > > > Hi all,
> > > > 
> > > > I'm unable to complete buildworld with 2 recent svn revs I've
> > > > tried
> > > > (r314838 and r315059). I'm building for a slightly resource
> > > > constrained
> > > > production system so am specifying custom settings and a
> > > > different
> > > > obj
> > > > tree location so I can copy it to the target system. The error
> > > > persists
> > > > after an "rm -rf /usr/obj/*", and if parallel building is
> > > > disabled.
> > > > 
> > > > The underlying build system built from r314838 via simple "make
> > > > -C
> > > > /usr/src -s -j6 buildworld buildkernel" built and installed fine,
> > > > so
> > > > the
> > > > problem seems to be around the use of the build customisations.
> > > > 
> > > > Any clues?
> > > > 
> > > > Cheers,
> > > > Lawrence
> > > > 
> > > > 
> > > > root@builder-head-amd64:/usr/src # cat cust_make.conf
> > > > KERNCONF=GENERIC-NODEBUG
> > > > MALLOC_PRODUCTION=YES
> > > > 
> > > > root@builder-head-amd64:/usr/src # cat cust_src.conf
> > > > WITHOUT_PROFILE=1
> > > > 
> > > > root@builder-head-amd64:/usr/src # make
> > > > __MAKE_CONF=/usr/src/cust_make.conf
> > > > SRCCONF=/usr/src/cust_src.conf
> > > > MAKEOBJDIRPREFIX=/usr/obj/cust buildworld buildkernel
> > > > [...]
> > > > MK_AUTO_OBJ=no
> > > > MK_TESTS=no  UPDATE_DEPENDFILE=no  _RECURSING_CRUNCH=1
> > > > CC="cc -target x86_64-unknown-freebsd12.0
> > > > --sysroot=/usr/obj/cust/usr/src/tmp
> > > > -B/usr/obj/cust/usr/src/tmp/usr/bin
> > > > -O2 -pipe   -std=gnu99-Qunused-arguments  "  CXX="c++  -
> > > > target
> > > > x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/cust/usr/src/tmp
> > > > -B/usr/obj/cust/usr/src/tmp/usr/bin -O2 -pipe -Qunused-arguments
> > > > -Wno-c++11-extensions  "  make .MAKE.MODE="normal curdirOk=yes"
> > > > .MAKE.META.IGNORE_PATHS=""  -f rescue.mk exe
> > > > cc -target x86_64-unknown-freebsd12.0
> > > > --sysroot=/usr/obj/cust/usr/src/tmp
> > > > -B/usr/obj/cust/usr/src/tmp/usr/bin
> > > > -O2 -pipe   -std=gnu99-Qunused-arguments   -nostdlib -Wl,-dc
> > > > -r
> > > > -o
> > > > cat.lo cat_stub.o
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o
> > > > cc: error: no such file or directory:
> > > > '/usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o'
> > > > *** Error code 1
> > > > 
> > > > There appear to be a lot of missing .o files under the rescue obj
> > > > tree:
> > > > 
> > > > root@builder-head-amd64:/usr/src # find
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr -type f
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax.o
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes.o
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/sh.err.h
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/tc.const.h
> > > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/gethost
> > > > 
> > > > compared with an obj tree on a different head system:
> > > > 
> > > > find /usr/obj/usr/src/rescue/rescue/usr/ -type f | wc -l
> > > > 1552
> > > > ___
> > > > freebsd-current@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre
> > > > ebsd
> > > > .org"  
> > > The MAKEOBJDIRPREFIX variable must be set in the environment, not
> > > in
> > > make.conf or on the make command line (documented in build(7)).  
> > Your assertion seems at odds with my past experience and my reading
> > of
> > the man page... from build(7):
> > 
> > The build may be controlled by defining make(1) variables
> > described in the ENVIRONMENT section below, and by the
> > variables documented in make.conf(5).
> > 
> > ... which indicates they are make variables, not environment
> > variables
> > specifically. As a concrete example, TARGET and DESTDIR are listed
> > under
> > the "ENVIRONMENT" section of the man page, yet "EXAMPLES" shows:
> > 
> >    make TARGET=sparc64 buildworld
> >    make TARGET=sparc64 DESTDIR=/clients/sparc64 installworld
> > 
> > I've certainly always set build vars documented in the "ENVIRONMENT"
> > section of the man page on the make command line without issue.
> > Pretty
> > sure I've set MAKEOBJDIRPREFIX from the make command line also in the
> > past, though perhaps it has been working for me "by accident" and a
> > documentation tweak is in order if the distinction you make is in
> > fact
> > relevant...
> > 
> > Cheers,
> > Lawrence
> > ___
> > 

Re: Boot failure - svn up from this morning

[Subbsd]

Hi,

I had the same problems, however, there is one more regression after
these changes. It stably reproduces if you use EFI_STAGING_SIZE.
I have custom FreeBSD distributive which has a sufficiently large
mfsroot which is loaded through UEFI mode.

To solve the problem, it was suggested to increase this variable and
rebuild /sys/boot:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209944

Also, it has to be increased periodically for some reason:

https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=305779=305778=305779

I've try to ask why than threatens to increase this parameter at once
large (or make it dependent on RAM):
https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050142.html
but there are no answer options.

At the moment, on r315141 boot via UEFI is fixed without EFI_STAGING_SIZE.

With EFI_STAGING_SIZE=768 i got regression after last changes in panic
with follow message:

failed to allocate staging area:9
failed to allocate stating area
Failed to start image provided by ZFS (5)

http://pasteboard.co/IvbhU9Ffu.jpg

I believe that there mfsroot may be greater than 64MB soon or later.

Also there are no problems with loading big mfsroot images when MBR
method is used.

PS:  I have ZFS-on-root system. With EFI_STAGING_SIZE=768 I lived with
constant CURRENT svnup/rebuilds for about a year. So I will be glad if
you pay attention to this.

PPS: How to reproduce:

1) EFI_STAGING_SIZE=768 in /etc/make.conf
2) make -C /sys/boot clean
3) make -C /sys/boot
4) make -C /sys/boot install
5) reboot

Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

deadlock in current (r314698)?

[Alexander Leidinger]

Hi,

do we have a known deadlock with r314698?

I have a system which locks up and some seconds later the watchdog  
kicks in and reboots. Sometimes it survives a day or two, sometimes it  
reboots more than once a day. I'm rebuilding the kernel with WITNESS  
now, but if someone is aware of a deadlock somewhere please tell.


Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp2GNaFtZUlA.pgp
Description: Digitale PGP-Signatur

Re: buildworld error

[Dimitry Andric]

On 12 Mar 2017, at 02:46, Cy Schubert  wrote:
> 
> In message <5cb065b0-5a7d-4a50-a722-8ea579a67...@freebsd.org>, Dimitry
> Andric w
> rites:
>> 
>> 
>> --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7
>> Content-Transfer-Encoding: quoted-printable
>> Content-Type: text/plain;
>>  charset=us-ascii
>> 
>> On 12 Mar 2017, at 01:55, Roberto Rodriguez Jr  =
>> wrote:
>>> =20
>>> Now...
>>> make buildworld
>> ...
>>> In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15:
>>> In file included from =
>> /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20:
>>> In file included from
>>> /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19:
>>> In file included from /usr/include/c++/v1/algorithm:634:
>>> In file included from /usr/include/c++/v1/memory:604:
>>> /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' =
>> file not
>>> found
>>> #include <__undef___deallocate>
>>>^
>> 
>> Yes, this is because of the bad advice to run "make delete-old" before
>> you had run "make installworld".  You had an older version of libc++ in
>> /usr/include/c++, but that still required the __undef___deallocate
>> header, which has now been deleted by "make delete-old".
>> 
>> Your best chance is to build and install libc++ first, if possible, by
>> doing:
>> 
>> cd /usr/src/lib/libc++
>> make obj
>> make depend
>> make
>> make install
>> 
>> Then retry building world.
> 
> If this actually fixes it, it (the build) is wrong. You shouldn't have to
> build and install src in order to build another part of src.
> 
> The procedure has always been documented as make installworld first then
> make delete-old. Failing to do so will on rare occasions bite you when
> building a port.

Yes, but in this case Roberto ran "make delete-old" *before* installing
world, on your advice. That is definitely something that should be
avoided.

E.g., "make delete-old" should only ever be run with exactly the same
source tree that your current world was installed from.  And preferably
right after "make installworld" and updating /etc.

-Dimitry



signature.asc
Description: Message signed with OpenPGP