Re: buildworld error
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
deadlock in current (r314698)?
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: Boot failure - svn up from this morning
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&r2=305778&pathrev=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"
Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX
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 > > ___ > > freebsd-current@freeb
Re: buildworld error
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: process killed: text file modification
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&view=markup#l1674
> > > >
> > > >
> > > > It's the NFS_TIMESPEC_COMPARE(&np->n_mtime, &np-
> > > > >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 &np->n_vattr.na_mtime: -3298114786616 +
> > -3298114786608
> > Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed:
> > text
> > file modificati
FreeBSD-current, panic on UEFI boot after recent changes
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&r2=305778&pathrev=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: buildworld error
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"
Re: buildworld error
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
> 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
FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
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"
