Re: clang 3.2 RC2 miscompiles libgcc?
On 01/11/13 00:39, Dimitry Andric wrote: On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. ___ Very appreciated and thanks. oh signature.asc Description: OpenPGP digital signature
Re: Circular port dependency
11.01.2013 03:21, George Mitchell: I grabbed the ports tree as of 308518, the RELEASE_9_1_0 tag. The current and supported version of ports is HEAD. devel/libtool won't build, because it requires autom4te during the Can you provide some logs showing how it can't be built? configure phase. So I put BUILD_DEPENDS= autom4te:devel/autoconf in the Makefile. But autoconf depends on gmake, which depends on gettext, which depends on libiconv, which depends on libtool. What to do? -- Sphinx of black quartz, judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Expanding ZFS RAIDZ on the fly?
On Fri, Jan 11, 2013 at 7:10 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: My question may sound naiv, sorry. I have already set up a RAIDZ (on FreeBSD 10.0-CUR), comprised with three 3 TB disks. I'd like to expand the array with an additional disk - on the fly. oh It's not possible to expand by just 1 disk. Expanding with another 3 disks is possible though, or backup, destroy, create, restore. Expanding or reducing the number of disks in a raidz is the mythical block pointer rewrite functionality, google will tell more. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Expanding ZFS RAIDZ on the fly?
On Fri, Jan 11, 2013 at 10:39:10AM +, Tom Evans wrote: On Fri, Jan 11, 2013 at 7:10 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: My question may sound naiv, sorry. I have already set up a RAIDZ (on FreeBSD 10.0-CUR), comprised with three 3 TB disks. I'd like to expand the array with an additional disk - on the fly. oh It's not possible to expand by just 1 disk. Expanding with another 3 disks is possible though, or backup, destroy, create, restore. Expanding or reducing the number of disks in a raidz is the mythical block pointer rewrite functionality, google will tell more. Another growth path is replacing each of the existing disks by larger ones and resilvering the data with 'zpool replace ...'. Having a spare drive bay is really a help so if you wanted to add just a 4th drive because you've only one bay left you should consider leaving that one unoccupied so you can easily grow to bigger disks now or in the future. HTH Paul Schenkeveld ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: installworld failure due to cross-device links
On 01/02/13 13:26, Nathan Whitehorn wrote: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. Similarly, 'make distribution' fails when /root is a separate filesystem: cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile /tmproot/root/.profile; rm -f /tmproot/.profile; ln /tmproot/root/.profile /tmproot/.profile ln: /tmproot/.profile: Cross-device link *** [distribution] Error code 1 Is there any real advantage of hard links over symlinks nowadays? -- Sorry for the following... The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
fixed breaking in libc ABI
On December 18th I made a commit that accidentally broke the libc ABI,
the commit below fixes it. If you updated current in the interim and
rebuilt ports due to complaints about strunvis or strunvisx you will
need to do so again after your next update. Sorry for the breakage.
-- Brooks
- Forwarded message from Brooks Davis bro...@freebsd.org -
From: Brooks Davis bro...@freebsd.org
Date: Fri, 11 Jan 2013 15:50:01 + (UTC)
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org
Subject: svn commit: r245305 - head/lib/libc/gen
Author: brooks
Date: Fri Jan 11 15:50:01 2013
New Revision: 245305
URL: http://svnweb.freebsd.org/changeset/base/245305
Log:
In r244401 I accidently moved strunvis and strunvisx from version 1.0 to
1.3 breaking the libc ABI. Revert that change (breaking the ABI again
for users who updated after December 18th).
Modified:
head/lib/libc/gen/Symbol.map
Modified: head/lib/libc/gen/Symbol.map
==
--- head/lib/libc/gen/Symbol.mapFri Jan 11 15:05:55 2013
(r245304)
+++ head/lib/libc/gen/Symbol.mapFri Jan 11 15:50:01 2013
(r245305)
@@ -298,6 +298,8 @@ FBSD_1.0 {
ualarm;
ulimit;
uname;
+ strunvis;
+ strunvisx;
usleep;
utime;
valloc;
@@ -391,8 +393,6 @@ FBSD_1.3 {
snvis;
strnunvis;
strnunvisx;
- strunvis;
- strunvisx;
strnvis;
strnvisx;
strsnvis;
- End forwarded message -
pgpEF9iX4S7wH.pgp
Description: PGP signature
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-11 02:19, O. Hartmann wrote: On 01/11/13 00:39, Dimitry Andric wrote: On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. ___ Very appreciated and thanks. oh For the record, I rebuilt my world/kernel after this commit, and rebuilt VirtualBox, and it now works correctly. Thanks Dimitry! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Parallel buildworld broken by clang
It seems that a parallel buildworld is broken by clang. % cd /usr/src % svn update % svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 245280 % make -j 5 buildworld ... === lib/clang/include (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/__wmmintrin_aes.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/__wmmintrin_pclmul.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/altivec.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/ammintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx2intrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avxintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/bmi2intrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/bmiintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/cpuid.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/emmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers /f16cintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/fma4intrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/fmaintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/immintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/lzcntintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/mm3dnow.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/mm_malloc.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/mmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/module.map /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/nmmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/pmmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/popcntintrin.h /usr/src/lib/clang/include/../../../co ntrib/llvm/tools/clang/lib/Headers/rtmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/smmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/tmmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/wmmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/x86intrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/xmmintrin.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/xopintrin.h /usr/obj/usr/src/tmp/usr/include/clang/3.2 1 error *** [_includes] Error code 2 1 error *** [buildworld] Error code 2 1 error hpc:root:exit:[212] -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r245310: /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3
When building the system, I receive very quickly the following error when /usr/src/lib/libcxxrt is compiled: c++ -fpic -DPIC -O2 -pipe -O3 -march=native -I/usr/src/lib/libcxxrt/../../contrib/libcxxrt -Qunused-arguments -fstack-protector -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -stdlib=libc++ -std=c++11 -c /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc -o memory.So /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3 /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3 return ATOMIC_SWAP(new_handl, handler); return ATOMIC_SWAP(new_handl, handler); ^~~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:14:47: note: expanded from macro 'ATOMIC_SWAP' __atomic_exchange(addr, val, __ATOMIC_ACQ_REL) ~^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:69:10: error: too few arguments to function call, expected 3, have 2 return ATOMIC_LOAD(new_handl); ^~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ ^~~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:14:47: note: expanded from macro 'ATOMIC_SWAP' __atomic_exchange(addr, val, __ATOMIC_ACQ_REL) ~^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:69:10: error: too few arguments to function call, expected 3, have 2 return ATOMIC_LOAD(new_handl); ^~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. 1 warning and 2 errors generated. *** [memory.So] Error code 1 *** [memory.o] Error code 1 2 errors *** [lib/libcxxrt__L] Error code 2 1 error *** [libraries] Error code 2 1 error *** [_libraries] Error code 2 1 error *** [buildworld] Error code 2 1 error signature.asc Description: OpenPGP digital signature
[panic] Unknown caching mode 8198 in sys/amd64/amd64/pmap.c
Hi, I'm running a relatively recent -CURRENT: root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # uname -a FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #50 r244773: Mon Dec 31 16:07:53 EST 2012 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 I ran into this panic twice over the past 24 hours. Both times, Chromium was the program I was actively using, with a few ssh sessions in the background. Below follows kgdb session and hopefully useful information. Any advice on how to further debug this would be appreciated. Glen Script started on Fri Jan 11 14:58:16 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # kgdb kernel.debug /var/crash/vmcore.6 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: panic: Unknown caching mode 8198 cpuid = 3 KDB: stack backtrace: #0 0x80605a76 at kdb_backtrace+0x66 #1 0x805c at panic+0x13b #2 0x80879748 at pmap_cache_bits+0x58 #3 0x80880fb4 at pmap_enter+0xa4 #4 0x8084ed25 at vm_fault_hold+0x1a15 #5 0x8084f8d3 at vm_fault+0x73 #6 0x8088593a at trap_pfault+0x13a #7 0x80886184 at trap+0x4f4 #8 0x8086f853 at calltrap+0x8 Uptime: 1d14h30m4s Dumping 4646 out of 7951 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdir/boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bootdir/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /bootdir/boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /bootdir/boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /bootdir/boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /bootdir/boot/kernel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/kernel/sem.ko...Reading symbols from /bootdir/boot/kernel/sem.ko.symbols...done. done. Loaded symbols for /boot/kernel/sem.ko Reading symbols from /boot/kernel/acpi_asus.ko...Reading symbols from /bootdir/boot/kernel/acpi_asus.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_asus.ko Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /bootdir/boot/kernel/aesni.ko.symbols...done. done. Loaded symbols for /boot/kernel/aesni.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /bootdir/boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /bootdir/boot/kernel/i915kms.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915kms.ko Reading symbols from /boot/kernel/iicbb.ko...Reading symbols from /bootdir/boot/kernel/iicbb.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbb.ko Reading symbols from /boot/kernel/iicbus.ko...Reading symbols from /bootdir/boot/kernel/iicbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbus.ko Reading symbols from /boot/kernel/iic.ko...Reading symbols from /bootdir/boot/kernel/iic.ko.symbols...done. done. Loaded symbols for /boot/kernel/iic.ko Reading symbols from /boot/kernel/agp.ko...Reading symbols from /bootdir/boot/kernel/agp.ko.symbols...done. done. Loaded symbols for /boot/kernel/agp.ko Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /bootdir/boot/kernel/drm2.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm2.ko Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done. Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko #0 doadump (textdump=value optimized out) at pcpu.h:229 229 __asm(movq %%gs:%1,%0 : =r (td) (kgdb) bt #0 doadump (textdump=value optimized out) at pcpu.h:229 #1 0x805cb724 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:446 #2 0x805cbba5 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:753 #3 0x80879748 in pmap_cache_bits (mode=value optimized out, is_pde=value optimized out) at /usr/src/sys/amd64/amd64/pmap.c:863 #4 0x80880fb4 in pmap_enter (pmap=0xfe01bfa66440, va=34636066816, access=value optimized out,
Re: installworld failure due to cross-device links
On Fri, Jan 11, 2013 at 6:18 AM, Matt Burke mattbli...@icritical.com wrote: On 01/02/13 13:26, Nathan Whitehorn wrote: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. Similarly, 'make distribution' fails when /root is a separate filesystem: cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile /tmproot/root/.profile; rm -f /tmproot/.profile; ln /tmproot/root/.profile /tmproot/.profile ln: /tmproot/.profile: Cross-device link *** [distribution] Error code 1 Is there any real advantage of hard links over symlinks nowadays? Yes. In fact, hard links are essential for some purposes. Key advantage of hard links is that you can create and use them as long as needed and then just delete them. Any remaining hard links are unaffected. When the last hard link is deleted, so is the file. Symlinks, on the other hand are simply pointer to a real file and if the file is deleted, the symlink remains, but is broken. Of course, symlinks can cross file systems when hard links can't. Both are likely to remain useful and neither is appropriate for all applications. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FILE's _file can only hold a short
On Wednesday, October 31, 2012 02:12:55 PM m...@freebsd.org wrote: I seem to recall a thread earlier on this limitation, but looking at actual libc/stdio sources, the 4 year old check for open(2)'s fd being less than SHRT_MAX is still there. I thought I saw a patch to change this to an int, but it's not in the tree. Was this in a PR or a mailing list thread or am I just imagining things? We've run into this limitation at work, where some processes have around 32k open file descriptors and then try to use the libc FILE interface. Since we control ABI we can just change this to int, but I had been hoping there was a FreeBSD revision we could pull instead of having another diff. I had been working on a port-exp run. The problem I have run into is that perl actually reaches inside of FILE directly to clear out _file so it can control when the fd is actually closed (really gross). I have extended my stuff so that old Perl binaries should still work, but wanted to figure out how to prevent future Perl binaries from growing the same dependency. Also, I haven't had a chance to do a follow-up to find what else out in ports-land tries to use _file directly from FILE. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysutils/lsof Author Question (for CLANG)....
On Wednesday, November 07, 2012 06:15:21 PM Eitan Adler wrote: On 7 November 2012 17:35, Larry Rosenman l...@lerctr.org wrote: On 2012-11-07 15:39, Greg 'groggy' Lehey wrote: On Wednesday, 7 November 2012 at 10:32:23 -0500, Benjamin Kaduk wrote: Once again, attempting to use kernel internals outside of the supported interfaces is just asking for trouble; I do not understand why this message is not sinking in over the course of your previous mails to these lists, so I will not try to belabor it further. IIRC lsof is a special case that always needs to be built with intimate knowledge of the kernel. This is VERY true. Since some of the information lsof uses has no API/ABI/KPI/KBI to get, it grovels around in the kernel. Can you tell us what interfaces you need? Perhaps we can either point you to ones that may work better or seek provide (stable) kernel features? The sysctls used by procstat -f and -v are close, (better than kern.files for example). However, lsof also reads other things we don't export such as the file descriptor locking state (flock(), etc.) and that requires direct access to KVM still. If you want to fix it, try to port lsof to use sysctls and see what you run into. The code isn't that hard to work with. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on arm/arm
On Friday, November 09, 2012 05:47:43 PM Adrian Chadd wrote: On 9 November 2012 14:37, Chuck Burns brea...@gmail.com wrote: Adrian. diskspace and cpu cycles are things I can spare, drop me a line outside of the ML and we can discuss particulars. It's just a personal box.. on a residential internet service, I have an amd64 box with 600G free on my pool.. 8G ram.. and I have a smaller i386 box... 100G or so free, 512M ram.. just drop me a line.. Hi, Those I do have - I have access to all of the ref* boxes in the cluster. I'm just typically hacking on this stuff on the train or at a cafe, and I don't have a workflow setup for pushing out potential diffs to build machines that have all the grunt/disk space for each little change that I do. I'm sorry about breaking things from time to time, but besides a small handful of what was I thinking?! things, the build breaks are just that - build breaks. They're easily fixed. This is why I use p4 branches. I hack on my laptop and then commit it to p4 and use 'p4 sync' as a glorified rsync on development hosts. I can then do a full 'make tinderbox' before committing to HEAD after extracting the patches from p4 and applying them to an SVN checkout. SVN branches should let you do something similar as well (or just about any soure code control system you choose to use). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No ATA disks on 9.1-RC3
On Monday, November 19, 2012 03:24:19 AM Alex Keda wrote: I try update my laptop - Compaq 6715s from 9.0 to 9.1-rc3 it cannot boot, because no HDD found dmesg from 9.0/9.1 and pciconf in attached files Can you get a verbose dmesg from 9.0? Also, if at all possible, it would be very helpful to get the full verbose dmesg from both 9.0 and 9.1 (the 9.1 one is truncated at the top). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: syscall cost freebsd vs linux ?
On Tuesday, November 27, 2012 01:41:46 AM Andrey Zonov wrote: On 11/19/12 11:32 PM, Luigi Rizzo wrote: today i was comparing the performance of some netmap-related code on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that our system calls are significantly slower. On comparable hardware (i7-2600k vs E5-1650) the syscall getppid() takes about 95ns on FreeBSD and 38ns on linux. (i make sure not to use gettimeofday(), which in linux is through vdso, and getpid(), which is cached by glibc). Any idea on why there is this difference and whether/how we can reduce it ? This is the cost of blocking mutexes. Linux uses RCU instead [1]. Here are the numbers on current: $ time ./getppid 1 real 0m22.926s user 0m2.252s sys 0m20.669s After locking removing (patch below): $ time ./getppid 1 real 0m15.224s user 0m2.355s sys 0m12.868s Unfortunately, RCU can be used only in GPL code, but we can use passive serialization for simple deref. And even more, it's already implemented in NetBSD. Of course, that is specific to getppid(). Micro-optimizing getppid() is probably not all that useful, and I suspect Luigi is more concerned about syscall overhead as it impacts other system calls. Perhaps compare getppid() on Linux with getpid() on FreeBSD. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Spurious witness warning when destroying spin mtx
On Friday, November 23, 2012 10:08:28 PM Ryan Stone wrote:
Today I saw a spurious witness warning for acquiring duplicate lock of
same type. The root cause is that when running mtx_destroy on a spinlock
that is held by the current thread, mtx_destroy calls spinlock_exit()
before calling WITNESS_UNLOCK, which opens up a window in which the CPU can
be interrupted and attempt to acquire another spinlock of the same type as
the one being destroyed. This patch should fix it:
diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c
index 2f13863..96f43f8 100644
--- a/sys/kern/kern_mutex.c
+++ b/sys/kern/kern_mutex.c
@@ -918,16 +918,16 @@ _mtx_destroy(volatile uintptr_t *c)
else {
MPASS((m-mtx_lock (MTX_RECURSED|MTX_CONTESTED)) == 0);
+ lock_profile_release_lock(m-lock_object);
+ /* Tell witness this isn't locked to make it happy. */
+ WITNESS_UNLOCK(m-lock_object, LOP_EXCLUSIVE, __FILE__,
+ __LINE__);
+
/* Perform the non-mtx related part of mtx_unlock_spin().
*/ if (LOCK_CLASS(m-lock_object) == lock_class_mtx_spin)
spinlock_exit();
else
curthread-td_locks--;
-
- lock_profile_release_lock(m-lock_object);
- /* Tell witness this isn't locked to make it happy. */
- WITNESS_UNLOCK(m-lock_object, LOP_EXCLUSIVE, __FILE__,
- __LINE__);
}
m-mtx_lock = MTX_DESTROYED
Ah, I would tweak this slightly perhaps to match mtx_unlock() and
mtx_unlock_spin():
if (LOCK_CLASS() == lock_class_mtx_sleep)
curthread-td_locks--;
/* lock profile and witness stuff */
if (LOCK_CLASS() == lock_class_mtx_spin)
spinlock_exit();
You are correct that it is broken for the spin case.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: page fault
On Friday, December 21, 2012 05:47:26 AM Ivan Klymenko wrote: В Tue, 14 Aug 2012 14:04:07 -0400 John Baldwin j...@freebsd.org пишет: On Tuesday, August 14, 2012 05:29:09 AM Ivan Klymenko wrote: http://privatepaste.com/147286442b It is easier to reply if the messages are inline (for future reference). The panic and relevant bit of backtrace are below. Sadly, trying to cut and paste this destroyed the formatting, so I've tried to fix it by hand. :( Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80933e07 stack pointer = 0x28:0xff823025b660 frame pointer = 0x28:0xff823025b6c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: bce0) trap number = 12 panic: page fault #6 0x80bb5e53 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0x80933e07 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:542 #8 0x809f8b76 in ip_fragment (ip=0xfe004b2f3980, m_frag=0xff823025b7c8, mtu=Variable mtu is not available. ) at /usr/src/sys/netinet/ip_output.c:822 #9 0x809f948a in ip_output (m=0xfe004b2f3900, opt=Variable opt is not available. ) at /usr/src/sys/netinet/ip_output.c:654 #10 0x809f59fa in ip_forward (m=0xfe004b2f3900, srcrt=Variable srcrt is not available. ) at /usr/src/sys/netinet/ip_input.c:1494 #11 0x809f6dc6 in ip_input (m=0xfe004b2f3900) at /usr/src/sys/netinet/ip_input.c:702 I apologize for not having answered - no more required files... At that time it was not possible to fulfill your request ... Now I have gained a number of similar panic's and i ready to provide the results. Can you run kgdb again and do 'frame 8' followed by 'p *m_frag', 'p m0', and 'p *m0'? kgdb.log in attach Looks like this attachment was lost unfortunately. Can you reply with the output inline (and include the output from the other kgdb commands below)? Can you also grab my gdb scripts at www.freebsd.org/~jhb/gdb/ and run 'cd /path/to/scripts', 'source gdb6', 'mbuf m0' as well? What kind of shell should I use for this? Ah, those are meant to be run while you are in kgdb. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Expanding ZFS RAIDZ on the fly?
Speaking of ZFS restriping, is anyone (Oracle/FreeBSD/etc.) actively working on block pointer rewrite functionality for ZFS? -- I FIGHT FOR THE USERS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FILE's _file can only hold a short
On Fri, Jan 11, 2013 at 7:44 AM, John Baldwin j...@freebsd.org wrote: On Wednesday, October 31, 2012 02:12:55 PM m...@freebsd.org wrote: I seem to recall a thread earlier on this limitation, but looking at actual libc/stdio sources, the 4 year old check for open(2)'s fd being less than SHRT_MAX is still there. I thought I saw a patch to change this to an int, but it's not in the tree. Was this in a PR or a mailing list thread or am I just imagining things? We've run into this limitation at work, where some processes have around 32k open file descriptors and then try to use the libc FILE interface. Since we control ABI we can just change this to int, but I had been hoping there was a FreeBSD revision we could pull instead of having another diff. I had been working on a port-exp run. The problem I have run into is that perl actually reaches inside of FILE directly to clear out _file so it can control when the fd is actually closed (really gross). I have extended my stuff so that old Perl binaries should still work, but wanted to figure out how to prevent future Perl binaries from growing the same dependency. Also, I haven't had a chance to do a follow-up to find what else out in ports-land tries to use _file directly from FILE. John, I posted a problem I am having with a perl script that opens multiple filehandles with output to a pipe (open $fh,command|;). The script has worked fine for over a decade, but an upgrade of FreeBSD from 7.2 to 8.3 caused the program to fail to transfer the entire output (between 14 and 30KB of data in lines of between 1 and 80 bytes. (Output of show bgp summary on a Juniper.) The sub-process just hangs until my watchdog sends a sigterm after 15 seconds. When I read the filehadle, I get only a truncated output from these processes. Others complete normally with full output. the failures tend to be ones with larger outputs, but not always. I have worked around this, but I would love to know why it broke in 8.3 after working since at least v5 and probably 4.3. Since this is a common technique or running multiple commands in parallel in perl, it would be nice if I could at least understand what is going on. This looks a bit like what this thread is discussing, but I am far from certain. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2013-01-11 20:50:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-11 20:50:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-11 20:50:16 - starting HEAD tinderbox run for i386/i386 TB --- 2013-01-11 20:50:16 - cleaning the object tree TB --- 2013-01-11 20:50:16 - /usr/local/bin/svn stat /src TB --- 2013-01-11 20:50:20 - At svn revision 245310 TB --- 2013-01-11 20:50:21 - building world TB --- 2013-01-11 20:50:21 - CROSS_BUILD_TESTING=YES TB --- 2013-01-11 20:50:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-11 20:50:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-11 20:50:21 - SRCCONF=/dev/null TB --- 2013-01-11 20:50:21 - TARGET=i386 TB --- 2013-01-11 20:50:21 - TARGET_ARCH=i386 TB --- 2013-01-11 20:50:21 - TZ=UTC TB --- 2013-01-11 20:50:21 - __MAKE_CONF=/dev/null TB --- 2013-01-11 20:50:21 - cd /src TB --- 2013-01-11 20:50:21 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jan 11 20:50:26 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-11 22:26:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-11 22:26:28 - ERROR: failed to build world TB --- 2013-01-11 22:26:28 - 4746.52 user 719.55 system 5771.76 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2013-01-11 20:50:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-11 20:50:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-11 20:50:16 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-01-11 20:50:16 - cleaning the object tree TB --- 2013-01-11 20:50:16 - /usr/local/bin/svn stat /src TB --- 2013-01-11 20:50:20 - At svn revision 245310 TB --- 2013-01-11 20:50:21 - building world TB --- 2013-01-11 20:50:21 - CROSS_BUILD_TESTING=YES TB --- 2013-01-11 20:50:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-11 20:50:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-11 20:50:21 - SRCCONF=/dev/null TB --- 2013-01-11 20:50:21 - TARGET=amd64 TB --- 2013-01-11 20:50:21 - TARGET_ARCH=amd64 TB --- 2013-01-11 20:50:21 - TZ=UTC TB --- 2013-01-11 20:50:21 - __MAKE_CONF=/dev/null TB --- 2013-01-11 20:50:21 - cd /src TB --- 2013-01-11 20:50:21 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jan 11 20:50:26 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-11 22:26:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-11 22:26:32 - ERROR: failed to build world TB --- 2013-01-11 22:26:32 - 4753.98 user 716.46 system 5775.46 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r245310: /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3
Dimitry cced. Sent from my iPhone On Jan 11, 2013, at 11:41 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: When building the system, I receive very quickly the following error when /usr/src/lib/libcxxrt is compiled: c++ -fpic -DPIC -O2 -pipe -O3 -march=native -I/usr/src/lib/libcxxrt/../../contrib/libcxxrt -Qunused-arguments -fstack-protector -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -stdlib=libc++ -std=c++11 -c /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc -o memory.So /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3 /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:64:10: error: too few arguments to function call, expected 4, have 3 return ATOMIC_SWAP(new_handl, handler); return ATOMIC_SWAP(new_handl, handler); ^~~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:14:47: note: expanded from macro 'ATOMIC_SWAP' __atomic_exchange(addr, val, __ATOMIC_ACQ_REL) ~^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:69:10: error: too few arguments to function call, expected 3, have 2 return ATOMIC_LOAD(new_handl); ^~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ ^~~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:14:47: note: expanded from macro 'ATOMIC_SWAP' __atomic_exchange(addr, val, __ATOMIC_ACQ_REL) ~^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:69:10: error: too few arguments to function call, expected 3, have 2 return ATOMIC_LOAD(new_handl); ^~~ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ /usr/src/lib/libcxxrt/../../contrib/libcxxrt/memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. 1 warning and 2 errors generated. *** [memory.So] Error code 1 *** [memory.o] Error code 1 2 errors *** [lib/libcxxrt__L] Error code 2 1 error *** [libraries] Error code 2 1 error *** [_libraries] Error code 2 1 error *** [buildworld] Error code 2 1 error ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Expanding ZFS RAIDZ on the fly?
On Fri, Jan 11, 2013 at 03:30:44PM -0500, Matthew X. Economou wrote: Speaking of ZFS restriping, is anyone (Oracle/FreeBSD/etc.) actively working on block pointer rewrite functionality for ZFS? If Oracle does it, I wouldn't expect to see it released in source code form for the rest of us to use. Regarding non-Oracle entities developing the code http://www.mail-archive.com/discuss@lists.illumos.org.hold.archive.listbox.com/msg2.html BPR doesn't look likely, unfortunately. Regards, Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/pc98
TB --- 2013-01-11 22:02:00 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-11 22:02:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-11 22:02:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-01-11 22:02:00 - cleaning the object tree TB --- 2013-01-11 22:02:00 - /usr/local/bin/svn stat /src TB --- 2013-01-11 22:02:03 - At svn revision 245310 TB --- 2013-01-11 22:02:04 - building world TB --- 2013-01-11 22:02:04 - CROSS_BUILD_TESTING=YES TB --- 2013-01-11 22:02:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-11 22:02:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-11 22:02:04 - SRCCONF=/dev/null TB --- 2013-01-11 22:02:04 - TARGET=pc98 TB --- 2013-01-11 22:02:04 - TARGET_ARCH=i386 TB --- 2013-01-11 22:02:04 - TZ=UTC TB --- 2013-01-11 22:02:04 - __MAKE_CONF=/dev/null TB --- 2013-01-11 22:02:04 - cd /src TB --- 2013-01-11 22:02:04 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jan 11 22:02:09 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-11 23:44:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-11 23:44:50 - ERROR: failed to build world TB --- 2013-01-11 23:44:50 - 5019.84 user 796.99 system 6169.86 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Circular port dependency
On 01/11/13 03:22, Gleb Kurtsou wrote: On (10/01/2013 20:21), George Mitchell wrote: I grabbed the ports tree as of 308518, the RELEASE_9_1_0 tag. devel/libtool won't build, because it requires autom4te during the configure phase. So I put BUILD_DEPENDS= autom4te:devel/autoconf in the Makefile. But autoconf depends on gmake, which depends on gettext, which depends on libiconv, which depends on libtool. What to do? Build devel/gmake defining WITHOUT_NLS: # cd /usr/ports/devel/gmake make -DWITHOUT_NLS all install Why would anybody want NLS support in make in a first place? I'm running on a CURRENT build on my Raspberry Pi. -- George Mitchell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org It turns out the circular dependency is the side effect of the FreeBSD 10 autotools fix. Upon discovering that acinclude.m4 has been modified, the port decides it needs to run autom4te. I worked around the problem with make -DWITHOUT_FBSD10_FIX, with no apparent ill effects. Perhaps the devel/libtool Makefile should always define WITHOUT_FBSD10_FIX. -- George Mitchell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2013-01-12 04:00:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-12 04:00:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-12 04:00:16 - starting HEAD tinderbox run for i386/i386 TB --- 2013-01-12 04:00:16 - cleaning the object tree TB --- 2013-01-12 04:02:39 - /usr/local/bin/svn stat /src TB --- 2013-01-12 04:02:42 - At svn revision 245321 TB --- 2013-01-12 04:02:43 - building world TB --- 2013-01-12 04:02:43 - CROSS_BUILD_TESTING=YES TB --- 2013-01-12 04:02:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-12 04:02:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-12 04:02:43 - SRCCONF=/dev/null TB --- 2013-01-12 04:02:43 - TARGET=i386 TB --- 2013-01-12 04:02:43 - TARGET_ARCH=i386 TB --- 2013-01-12 04:02:43 - TZ=UTC TB --- 2013-01-12 04:02:43 - __MAKE_CONF=/dev/null TB --- 2013-01-12 04:02:43 - cd /src TB --- 2013-01-12 04:02:43 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Jan 12 04:02:48 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-12 05:38:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-12 05:38:56 - ERROR: failed to build world TB --- 2013-01-12 05:38:56 - 4751.02 user 720.77 system 5919.77 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2013-01-12 04:00:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-12 04:00:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-12 04:00:16 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-01-12 04:00:16 - cleaning the object tree TB --- 2013-01-12 04:02:39 - /usr/local/bin/svn stat /src TB --- 2013-01-12 04:02:42 - At svn revision 245321 TB --- 2013-01-12 04:02:43 - building world TB --- 2013-01-12 04:02:43 - CROSS_BUILD_TESTING=YES TB --- 2013-01-12 04:02:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-12 04:02:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-12 04:02:43 - SRCCONF=/dev/null TB --- 2013-01-12 04:02:43 - TARGET=amd64 TB --- 2013-01-12 04:02:43 - TARGET_ARCH=amd64 TB --- 2013-01-12 04:02:43 - TZ=UTC TB --- 2013-01-12 04:02:43 - __MAKE_CONF=/dev/null TB --- 2013-01-12 04:02:43 - cd /src TB --- 2013-01-12 04:02:43 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Jan 12 04:02:47 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-12 05:39:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-12 05:39:12 - ERROR: failed to build world TB --- 2013-01-12 05:39:12 - 4757.20 user 718.62 system 5936.28 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/pc98
TB --- 2013-01-12 05:11:55 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-12 05:11:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-12 05:11:55 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-01-12 05:11:55 - cleaning the object tree TB --- 2013-01-12 05:12:31 - /usr/local/bin/svn stat /src TB --- 2013-01-12 05:12:34 - At svn revision 245321 TB --- 2013-01-12 05:12:35 - building world TB --- 2013-01-12 05:12:35 - CROSS_BUILD_TESTING=YES TB --- 2013-01-12 05:12:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-12 05:12:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-12 05:12:35 - SRCCONF=/dev/null TB --- 2013-01-12 05:12:35 - TARGET=pc98 TB --- 2013-01-12 05:12:35 - TARGET_ARCH=i386 TB --- 2013-01-12 05:12:35 - TZ=UTC TB --- 2013-01-12 05:12:35 - __MAKE_CONF=/dev/null TB --- 2013-01-12 05:12:35 - cd /src TB --- 2013-01-12 05:12:35 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Jan 12 05:12:39 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~ /src/lib/libc++/../../contrib/libcxxrt/atomic.h:25:38: note: expanded from macro 'ATOMIC_LOAD' __atomic_load(addr, __ATOMIC_ACQUIRE) ~ ^ cxxrt_memory.cc:149:6: warning: function previously declared with an implicit exception specification redeclared with an explicit exception specification [-Wimplicit-exception-spec-mismatch] void operator delete[](void * ptr) throw() ^ 1 warning and 2 errors generated. *** [cxxrt_memory.o] Error code 1 Stop in /src/lib/libc++. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-12 06:55:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-12 06:55:56 - ERROR: failed to build world TB --- 2013-01-12 06:55:56 - 5019.60 user 801.84 system 6240.99 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
