Re: [head tinderbox] failure on armv6/arm
Seems the tinderbox scripts are routinely showing too little of the actual error these days... On Jun 4, 2013, at 7:19 PM, FreeBSD Tinderbox wrote: TB --- 2013-06-05 01:10:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-06-05 01:10:18 - 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-06-05 01:10:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-06-05 01:10:18 - cleaning the object tree TB --- 2013-06-05 01:10:18 - /usr/local/bin/svn stat /src TB --- 2013-06-05 01:10:22 - At svn revision 251402 TB --- 2013-06-05 01:10:23 - building world TB --- 2013-06-05 01:10:23 - CROSS_BUILD_TESTING=YES TB --- 2013-06-05 01:10:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-05 01:10:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-05 01:10:23 - SRCCONF=/dev/null TB --- 2013-06-05 01:10:23 - TARGET=arm TB --- 2013-06-05 01:10:23 - TARGET_ARCH=armv6 TB --- 2013-06-05 01:10:23 - TZ=UTC TB --- 2013-06-05 01:10:23 - __MAKE_CONF=/dev/null TB --- 2013-06-05 01:10:23 - cd /src TB --- 2013-06-05 01:10:23 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Jun 5 01:10:30 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 [...] === cddl/lib/libavl (all) cc -O -pipe -I/src/cddl/lib/libavl/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -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-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c -o avl.o building static avl library ranlib libavl.a cc -fpic -DPIC -O -pipe -I/src/cddl/lib/libavl/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -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-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c -o avl.So building shared library libavl.so.2 /obj/arm.armv6/src/tmp/usr/bin/ld: cannot find -lgcc_s cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make: stopped in /src/cddl/lib/libavl *** Error code 1 Stop. make: stopped in /src/cddl/lib === cddl/lib/libavl (install) sh /src/tools/install.sh -C -o root -g wheel -m 444 libavl.a /obj/arm.armv6/src/tmp/usr/lib sh /src/tools/install.sh -s -o root -g wheel -m 444 libavl.so.2 /obj/arm.armv6/src/tmp/lib install: libavl.so.2: No such file or directory *** Error code 71 Stop. make: stopped in /src/cddl/lib/libavl *** Error code 1 Stop. make: stopped in /src/cddl/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-06-05 02:19:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-05 02:19:07 - ERROR: failed to build world TB --- 2013-06-05 02:19:07 - 3613.77 user 355.81 system 4128.80 real ___ 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
Recurring panic
Hi
I have the following recurring panic on all my heavily network
loaded -CURRENT routers. The current process is always different.
Gleb, can you please chime in with what you've managed to uncover.
Unread portion of the kernel message buffer:
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 21363 (kgdb)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b4de530
panic() at panic+0x13d/frame 0xff846b4de630
trap_fatal() at trap_fatal+0x290/frame 0xff846b4de690
trap_pfault() at trap_pfault+0x21f/frame 0xff846b4de6f0
trap() at trap+0x2b4/frame 0xff846b4de830
calltrap() at calltrap+0x8/frame 0xff846b4de830
--- trap 0xc, rip = 0x8044872d, rsp = 0xff846b4de8f0, rbp =
0xff846b4de910 ---
__mtx_lock_sleep() at __mtx_lock_sleep+0x5d/frame 0xff846b4de910
selfdfree() at selfdfree+0xef/frame 0xff846b4de930
sys_poll() at sys_poll+0x332/frame 0xff846b4dead0
amd64_syscall() at amd64_syscall+0x572/frame 0xff846b4debf0
Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b4debf0
--- syscall (209, FreeBSD ELF64, sys_poll), rip = 0x80160670a, rsp =
0x7fffcc68, rbp = 0 ---
Uptime: 3d5h49m17s
Dumping 2580 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:264
264 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:264
#1 0x8045a424 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2 0x8045a927 in panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:754
#3 0x8061e950 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x8061ecbf in trap_pfault (frame=0xff846b4de840, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:789
#5 0x8061f074 in trap (frame=0xff846b4de840)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0x806088ef in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#7 0x8044872d in __mtx_lock_sleep (c=0xff8006e551e8,
tid=18446741875506397184, opts=value optimized out,
file=value optimized out, line=0) at /usr/src/sys/kern/kern_mutex.c:425
#8 0x804a574f in selfdfree (stp=value optimized out,
sfp=0xfe02bbf92690) at /usr/src/sys/kern/sys_generic.c:1524
#9 0x804a6e82 in sys_poll (td=0xfe0030e1c000,
uap=0xff846b4deb70) at /usr/src/sys/kern/sys_generic.c:1369
#10 0x8061e2b2 in amd64_syscall (td=0xfe0030e1c000, traced=0)
at subr_syscall.c:134
#11 0x80608bd7 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:387
#12 0x00080160670a in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Ian
--
Ian Freislich
___
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: Recurring panic
On Wed, Jun 05, 2013 at 10:18:21AM +0200, Ian FREISLICH wrote: I I have the following recurring panic on all my heavily network I loaded -CURRENT routers. The current process is always different. I I Gleb, can you please chime in with what you've managed to uncover. The panics appear on selfd mutex. The mtx_lock value is a free mutex, but it has 1 extra bit set: (kgdb) p/x sfp-sf_mtx-mtx_lock $3 = 0x104 Rarely (only one panic observed) more than one bit is set: $3 = 0x2104 It is important that selfd mutexes are taken from mtxpool(9), which is allocated at a early boot stage. Thus, across reboots all possible sfp-sf_mtx mutexes usually fall into the same virtual memory region. I'm not sure, but I suppose, they fall into same physical region. This can lead one to idea that RAM in the box has problems. But it is running ECC memory, and it doesn't experience other random panics. The only special about the box is that it is running pf(4) with huge ruleset and a lot of traffic. So the pf(4) is the number one suspected, albeit it isn't closely related to selfds. -- Totus tuus, Glebius. ___ 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: Recurring panic
On Wed, Jun 05, 2013 at 01:50:43PM +0400, Gleb Smirnoff wrote: On Wed, Jun 05, 2013 at 10:18:21AM +0200, Ian FREISLICH wrote: I I have the following recurring panic on all my heavily network I loaded -CURRENT routers. The current process is always different. I I Gleb, can you please chime in with what you've managed to uncover. The panics appear on selfd mutex. The mtx_lock value is a free mutex, but it has 1 extra bit set: (kgdb) p/x sfp-sf_mtx-mtx_lock $3 = 0x104 Rarely (only one panic observed) more than one bit is set: $3 = 0x2104 It is important that selfd mutexes are taken from mtxpool(9), which is allocated at a early boot stage. Thus, across reboots all possible sfp-sf_mtx mutexes usually fall into the same virtual memory region. I'm not sure, but I suppose, they fall into same physical region. This can lead one to idea that RAM in the box has problems. But it is running ECC memory, and it doesn't experience other random panics. The only special about the box is that it is running pf(4) with huge ruleset and a lot of traffic. So the pf(4) is the number one suspected, albeit it isn't closely related to selfds. So is the virtual address of the corrupted word same for each panic ? If yes, set up the hw watchpoint in ddb. pgpoldij1FYhP.pgp Description: PGP signature
Re: Recurring panic
On Wed, Jun 05, 2013 at 01:13:45PM +0300, Konstantin Belousov wrote: K On Wed, Jun 05, 2013 at 01:50:43PM +0400, Gleb Smirnoff wrote: K On Wed, Jun 05, 2013 at 10:18:21AM +0200, Ian FREISLICH wrote: K I I have the following recurring panic on all my heavily network K I loaded -CURRENT routers. The current process is always different. K I K I Gleb, can you please chime in with what you've managed to uncover. K K The panics appear on selfd mutex. The mtx_lock value is a free mutex, but K it has 1 extra bit set: K K (kgdb) p/x sfp-sf_mtx-mtx_lock K $3 = 0x104 K K Rarely (only one panic observed) more than one bit is set: K K $3 = 0x2104 K K It is important that selfd mutexes are taken from mtxpool(9), which K is allocated at a early boot stage. Thus, across reboots all possible K sfp-sf_mtx mutexes usually fall into the same virtual memory region. K I'm not sure, but I suppose, they fall into same physical region. K K This can lead one to idea that RAM in the box has problems. But it K is running ECC memory, and it doesn't experience other random panics. K K The only special about the box is that it is running pf(4) with huge K ruleset and a lot of traffic. So the pf(4) is the number one suspected, K albeit it isn't closely related to selfds. K K So is the virtual address of the corrupted word same for each panic ? K If yes, set up the hw watchpoint in ddb. Nope, they are different, but close to each other, since live in the same mtxpool. -- Totus tuus, Glebius. ___ 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: Can't compile databases/py-sqlite3
On Tue, 04 Jun 2013 21:53:57 +0200, Dimitry Andric wrote: On Jun 4, 2013, at 21:15, Walter Hurry walterhu...@gmail.com wrote: I'm running 10.0-CORRENT on amd64. Ports and source are both up to date. When I try a 'make install' in /usr/ports/databases/py-sqlite3 I get this very early on: === FreeBSD 10 autotools fix applied to /usr/ports/databases/py- sqlite3/work/Python-2.7.5/configure running config jemalloc: /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/ internal/arena.h:547: Failed assertion: binind NBINS || binind == BININD_INVALID *** Signal 6 Stop. make: stopped in /usr/ports/databases/py-sqlite3 I'm afraid this binind business doesn't mean much to me. Is there anything I can do? Please try the patch from this very recent post (on this very list ;-): http://lists.freebsd.org/pipermail/freebsd-current/2013-June/042230.html Yes, that has fixed my problem. Thank you very much. By the way. sorry for not spotting it in the other thread. I searched for 'sqlite3' before posting, but found nothing. ___ 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: Cannot build ports on fresh 10.0
On 06/04/13 18:07, hiren panchasara wrote: On Tue, Jun 4, 2013 at 2:42 PM, m...@freebsd.org wrote: I installed a new VM with 10.0 today from this .iso: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/amd64/10.0/FreeBSD-10.0-CURRENT-amd64-20130601-r251213-release.iso And I'm behind a firewall and I'm not sure I can use pkg(1); my one attempt failed: # pkg install m4 Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy pkg: Package 'm4' was not found in the repositories So I'm building from source. But the configure step of various ports fails like so: checking whether make sets $(MAKE)... yes checking build system type... Invalid configuration `amd64-portbld-freebsd10.0': machine `amd64-portbld' not recognized configure: error: /bin/sh libltdl/config/config.sub amd64-portbld-freebsd10.0 failed === Script configure failed unexpectedly. Please report the problem to autoto...@freebsd.org [maintainer] and attach the /usr/ports/devel/libtool/work/libtool-2.4.2/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 _Probably_ similar to this? http://lists.freebsd.org/pipermail/freebsd-ports/2013-June/084040.html cheers, Hiren Any ideas what could be wrong? It's a fresh install with default options, so it seems hard to believe I managed to screw something up already. Posting on -current since this happens to many of the ports when I try to build them. Thanks, matthew ___ 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 ___ 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 What you see has been fixed in ports r319875. You can sync your tree to past that and try again. Also, you can try the same proxy settings from libfetch. - Nikolai Lifanov ___ 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: Memstick Images not working (mountroot prompt)
Forgot to CC the list, sorry! In the meantime I upgrade from 9.1 using the base and kernel tarballs, I could boot and I have wireless supported! I have my ssd encrypted and the hdd too, the hdd is encrypted with passphrase + key, and this key is in a usb stick (a different one form the other two already tried). The USB stick is not working to, and I also tried a USB Western Digital 500GB disk, no luck either! So no usb support basically... dmesg output after connecting the device: xhci_do_comand: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) usbgen0.2: Unknown at usbus0 (disconnected) usb_reattach_port: could not allocate new device Also note that usbus0 is a 3.0 as dmesg shows after boot: usbus0: waiting for BIOS to give up control usbus0 on xhci0 usbus0: 5.0Gpbs Super Speed USB v 3.0 So I guess this is indeed a problem in the 10.0-current kernel, not sure what it could be or what more can I do to debug though... Please advice, Thanks On Wed, Jun 5, 2013 at 4:54 AM, miguelmcl...@gmail.com wrote: I have no such option. Its a very recent ultrabook. Enviado a partir do meu smartphone BlackBerry® www.blackberry.com -Original Message- From: Glen Barber g...@freebsd.org Date: Tue, 4 Jun 2013 23:45:34 To: Miguel Claramiguelmcl...@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: Memstick Images not working (mountroot prompt) Hi, On Wed, Jun 05, 2013 at 04:33:19AM +0100, Miguel Clara wrote: Hello, I need to Install FreeBSD 10 on my laptop to have Wireless support for my card (ath) however I tried all of the available memstick images at: ftp://ftp.uk.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/ And none of them works... I've tried 2 different pen drivers, one of those is a generic cheap one, and another is a DKingston DT 100 G2 When typing ? in the mount root prompt I see my ssd and hdd are listed, but not the memstick (which I assume it should be da0). I had no problems with the 9.1 stable image using the same memstick! I have personally boot tested the memstick images, without problem. What is 'Legacy USB' set to in BIOS on your machine? Glen ___ 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: Memstick Images not working (mountroot prompt)
Please file a PR? hopefully someone from the USB side of things can help you fix this. Thanks! adrian On 5 June 2013 07:52, Miguel Clara miguelmcl...@gmail.com wrote: Forgot to CC the list, sorry! In the meantime I upgrade from 9.1 using the base and kernel tarballs, I could boot and I have wireless supported! I have my ssd encrypted and the hdd too, the hdd is encrypted with passphrase + key, and this key is in a usb stick (a different one form the other two already tried). The USB stick is not working to, and I also tried a USB Western Digital 500GB disk, no luck either! So no usb support basically... dmesg output after connecting the device: xhci_do_comand: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) usbgen0.2: Unknown at usbus0 (disconnected) usb_reattach_port: could not allocate new device Also note that usbus0 is a 3.0 as dmesg shows after boot: usbus0: waiting for BIOS to give up control usbus0 on xhci0 usbus0: 5.0Gpbs Super Speed USB v 3.0 So I guess this is indeed a problem in the 10.0-current kernel, not sure what it could be or what more can I do to debug though... Please advice, Thanks On Wed, Jun 5, 2013 at 4:54 AM, miguelmcl...@gmail.com wrote: I have no such option. Its a very recent ultrabook. Enviado a partir do meu smartphone BlackBerry® www.blackberry.com -Original Message- From: Glen Barber g...@freebsd.org Date: Tue, 4 Jun 2013 23:45:34 To: Miguel Claramiguelmcl...@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: Memstick Images not working (mountroot prompt) Hi, On Wed, Jun 05, 2013 at 04:33:19AM +0100, Miguel Clara wrote: Hello, I need to Install FreeBSD 10 on my laptop to have Wireless support for my card (ath) however I tried all of the available memstick images at: ftp://ftp.uk.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/ And none of them works... I've tried 2 different pen drivers, one of those is a generic cheap one, and another is a DKingston DT 100 G2 When typing ? in the mount root prompt I see my ssd and hdd are listed, but not the memstick (which I assume it should be da0). I had no problems with the 9.1 stable image using the same memstick! I have personally boot tested the memstick images, without problem. What is 'Legacy USB' set to in BIOS on your machine? Glen ___ 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 ___ 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: Memstick Images not working (mountroot prompt)
On Wed, Jun 05, 2013 at 03:52:44PM +0100, Miguel Clara wrote: Forgot to CC the list, sorry! In the meantime I upgrade from 9.1 using the base and kernel tarballs, I could boot and I have wireless supported! I have my ssd encrypted and the hdd too, the hdd is encrypted with passphrase + key, and this key is in a usb stick (a different one form the other two already tried). The USB stick is not working to, and I also tried a USB Western Digital 500GB disk, no luck either! So no usb support basically... dmesg output after connecting the device: xhci_do_comand: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) usbgen0.2: Unknown at usbus0 (disconnected) usb_reattach_port: could not allocate new device Also note that usbus0 is a 3.0 as dmesg shows after boot: usbus0: waiting for BIOS to give up control usbus0 on xhci0 usbus0: 5.0Gpbs Super Speed USB v 3.0 So I guess this is indeed a problem in the 10.0-current kernel, not sure what it could be or what more can I do to debug though... Please advice, Hmm. Can you please try with a USB 2.0 port on the laptop? (Hopefully it has at least one non-USB-3.0 port...) Glen pgpZBanAqSmeX.pgp Description: PGP signature
Re: Memstick Images not working (mountroot prompt)
Ok. Please open a PR as Adrian suggested, so we can properly track this. Glen On Wed, Jun 05, 2013 at 06:42:05PM +, miguelmcl...@gmail.com wrote: Sadly it doesn't... Just two ports in the back and in the same controller. Its an Intel Panter Point controller, but I'll add that info to the PR as soon has my girlfriend get out of farmville and let's me use her laptop xD Note: I also tried sysctl hw.xhci.xhci_port_route=-1 and =1 has I wasn't sure what would be correct but none of those helped! Thanks Enviado a partir do meu smartphone BlackBerry® www.blackberry.com -Original Message- From: Glen Barber g...@freebsd.org Date: Wed, 5 Jun 2013 14:08:00 To: Miguel Claramiguelmcl...@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: Memstick Images not working (mountroot prompt) On Wed, Jun 05, 2013 at 03:52:44PM +0100, Miguel Clara wrote: Forgot to CC the list, sorry! In the meantime I upgrade from 9.1 using the base and kernel tarballs, I could boot and I have wireless supported! I have my ssd encrypted and the hdd too, the hdd is encrypted with passphrase + key, and this key is in a usb stick (a different one form the other two already tried). The USB stick is not working to, and I also tried a USB Western Digital 500GB disk, no luck either! So no usb support basically... dmesg output after connecting the device: xhci_do_comand: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) usbgen0.2: Unknown at usbus0 (disconnected) usb_reattach_port: could not allocate new device Also note that usbus0 is a 3.0 as dmesg shows after boot: usbus0: waiting for BIOS to give up control usbus0 on xhci0 usbus0: 5.0Gpbs Super Speed USB v 3.0 So I guess this is indeed a problem in the 10.0-current kernel, not sure what it could be or what more can I do to debug though... Please advice, Hmm. Can you please try with a USB 2.0 port on the laptop? (Hopefully it has at least one non-USB-3.0 port...) Glen pgphoc95Tn0fP.pgp Description: PGP signature
another external compiler topic
For the diagnosis of an error related to external compilers, I'll post full
setup information.
Compiler version string: clang version 3.4 (trunk 182723).
Installed system revision: 251046.
Checked out source tree revision: 251352.
The following 2 configuration files were used to build the installed system, as well as
the new system. (However, see the compiler note later on.)
=== make.conf begins ===
CPUTYPE=native
KERNCONF=MYCONF
COMPILER_TYPE=clang
CROSS_COMPILER_PREFIX=
WITHOUT_FORMAT_EXTENSIONS=1
CC=/path/to/clang
CPP=/path/to/clang-cpp
CXX=/path/to/clang++
NO_CLEAN=1
NO_KERNELCLEAN=1
NO_MODULES=1
MALLOC_PRODUCTION=1
=== make.conf ends ===
=== src.conf begins ===
WITHOUT_ACCT=1
WITHOUT_ACPI=1
WITHOUT_AMD=1
WITHOUT_APM=1
WITHOUT_AT=1
WITHOUT_ATF=1
WITHOUT_ATM=1
WITHOUT_AUDIT=1
WITHOUT_AUTHPF=1
WITHOUT_BIND=1
WITHOUT_BLUETOOTH=1
WITHOUT_BSNMP=1
WITHOUT_CALENDAR=1
WITHOUT_CDDL=1
WITHOUT_CLANG=1
WITHOUT_CLANG_IS_CC=1
WITHOUT_CTM=1
WITHOUT_CVS=1
WITHOUT_DICT=1
WITHOUT_ED_CRYPTO=1
WITHOUT_FDT=1
WITHOUT_FLOPPY=1
WITHOUT_FREEBSD_UPDATE=1
WITHOUT_GAMES=1
WITHOUT_GCC=1
WITHOUT_GCOV=1
WITHOUT_GDB=1
WITHOUT_GPIB=1
WITHOUT_GPIO=1
WITHOUT_HESIOD=1
WITHOUT_HTML=1
WITHOUT_INET6=1
WITHOUT_INFO=1 # [1]
WITHOUT_IPFILTER=1
WITHOUT_IPFW=1
WITHOUT_IPX=1
WITHOUT_JAIL=1
WITHOUT_KDUMP=1
WITHOUT_KVM=1
WITHOUT_LDNS=1
WITHOUT_LEGACY_CONSOLE=1
WITHOUT_LOCATE=1
WITHOUT_LPR=1
WITHOUT_MAIL=1
WITHOUT_NDIS=1
WITHOUT_NETGRAPH=1
WITHOUT_NLS=1
WITHOUT_NLS_CATALOGS=1
WITHOUT_NTP=1
WITHOUT_PC_SYSINSTALL=1
WITHOUT_PF=1
WITHOUT_PKGTOOLS=1
WITHOUT_PMC=1
WITHOUT_PORTSNAP=1
WITHOUT_PPP=1
WITHOUT_PROFILE=1
WITHOUT_QUOTAS=1
WITHOUT_RCMDS=1
WITHOUT_RCS=1
WITHOUT_RESCUE=1
WITHOUT_SENDMAIL=1
WITHOUT_SHAREDOCS=1
WITHOUT_SYSINSTALL=1
WITHOUT_TELNET=1
WITHOUT_WIRELESS=1
WITHOUT_WPA_SUPPLICANT_EAPOL=1
WITH_BSD_GREP=1
WITH_BSD_PATCH=1
=== src.conf ends ===
For the interested reader, regarding # [1]:
=== /usr/bin/makeinfo begins ===
B=
for i in $@ ; do
if test -n $B ; then
echo fuck this shit $i
exit 0
fi
if test $i = -o ; then
B=1
fi
done
=== /usr/bin/makeinfo ends ===
The following are output log snippets. (Snippet 2 contains an error that
follows snippet 1; key term: parallel builds (most likely).)
=== `make buildworld` snippet 1 begins ===
building shared library libkadm5srv.so.11
=== kerberos5/lib/libkafs5 (all)
/i/a/clang -O2 -pipe -march=native
-I/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs
-I/usr/src/kerberos5/li
b/libkafs5/../../../crypto/heimdal/lib/krb5
-I/usr/obj/usr/src/kerberos5/lib/libkafs5/../libkrb5/
-I/usr/src/kerberos5/lib/li
bkafs5/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H
-I/usr/src/kerberos5/lib/libkafs5/../../include -std=gnu99 -Qunused-ar
guments -fstack-protector -c
/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/afssys.c -o
afssys.o
In file included from
/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/afssys.c:34:
In file included from
/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/kafs_locl.h:99:
/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/krb5/krb5-v4compat.h:39:10:
fatal error: 'krb_err.h' file not found
=== `make buildworld` snippet 1 ends ===
=== `make buildworld` snippet 2 begins ===
=== kerberos5/lib/libkafs5 (install)
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libkafs5.a
/usr/obj/usr/src/tmp/usr/lib
install: libkafs5.a: No such file or directory
=== `make buildworld` snippet 2 ends ===
When building the system that is currently installed, the following compiler
was used:
=== /path/to/clang begins ===
#!/bin/sh
/path/to/real/clang $@ || /path/to/real/clang --sysroot=/usr/obj/usr/src/tmp
$@
=== /path/to/clang ends ===
Also, the following patch was applied to the source tree:
=== diff begins ===
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 251352)
+++ Makefile.inc1 (working copy)
@@ -722,7 +722,7 @@
ITOOLS=[ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep id install ${_install-info} \
ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp dd
#
# distributeworld
Index: usr.bin/xlint/llib/Makefile
===
--- usr.bin/xlint/llib/Makefile (revision 251352)
+++ usr.bin/xlint/llib/Makefile (working copy)
@@ -9,9 +9,9 @@
CLEANFILES+= ${LIBS}
llib-lposix.ln: llib-lposix
- ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
llib-lstdc.ln: llib-lstdc
- ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
.include bsd.prog.mk
=== diff
Re: Memstick Images not working (mountroot prompt)
Sadly it doesn't... Just two ports in the back and in the same controller. Its an Intel Panter Point controller, but I'll add that info to the PR as soon has my girlfriend get out of farmville and let's me use her laptop xD Note: I also tried sysctl hw.xhci.xhci_port_route=-1 and =1 has I wasn't sure what would be correct but none of those helped! Thanks Enviado a partir do meu smartphone BlackBerry® www.blackberry.com -Original Message- From: Glen Barber g...@freebsd.org Date: Wed, 5 Jun 2013 14:08:00 To: Miguel Claramiguelmcl...@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: Memstick Images not working (mountroot prompt) On Wed, Jun 05, 2013 at 03:52:44PM +0100, Miguel Clara wrote: Forgot to CC the list, sorry! In the meantime I upgrade from 9.1 using the base and kernel tarballs, I could boot and I have wireless supported! I have my ssd encrypted and the hdd too, the hdd is encrypted with passphrase + key, and this key is in a usb stick (a different one form the other two already tried). The USB stick is not working to, and I also tried a USB Western Digital 500GB disk, no luck either! So no usb support basically... dmesg output after connecting the device: xhci_do_comand: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) usbgen0.2: Unknown at usbus0 (disconnected) usb_reattach_port: could not allocate new device Also note that usbus0 is a 3.0 as dmesg shows after boot: usbus0: waiting for BIOS to give up control usbus0 on xhci0 usbus0: 5.0Gpbs Super Speed USB v 3.0 So I guess this is indeed a problem in the 10.0-current kernel, not sure what it could be or what more can I do to debug though... Please advice, Hmm. Can you please try with a USB 2.0 port on the laptop? (Hopefully it has at least one non-USB-3.0 port...) Glen ___ 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: Memstick Images not working (mountroot prompt)
Done: http://www.freebsd.org/cgi/query-pr.cgi?pr=179342 On Wed, Jun 5, 2013 at 7:45 PM, Glen Barber g...@freebsd.org wrote: Ok. Please open a PR as Adrian suggested, so we can properly track this. Glen On Wed, Jun 05, 2013 at 06:42:05PM +, miguelmcl...@gmail.com wrote: Sadly it doesn't... Just two ports in the back and in the same controller. Its an Intel Panter Point controller, but I'll add that info to the PR as soon has my girlfriend get out of farmville and let's me use her laptop xD Note: I also tried sysctl hw.xhci.xhci_port_route=-1 and =1 has I wasn't sure what would be correct but none of those helped! Thanks Enviado a partir do meu smartphone BlackBerry® www.blackberry.com -Original Message- From: Glen Barber g...@freebsd.org Date: Wed, 5 Jun 2013 14:08:00 To: Miguel Claramiguelmcl...@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: Memstick Images not working (mountroot prompt) On Wed, Jun 05, 2013 at 03:52:44PM +0100, Miguel Clara wrote: Forgot to CC the list, sorry! In the meantime I upgrade from 9.1 using the base and kernel tarballs, I could boot and I have wireless supported! I have my ssd encrypted and the hdd too, the hdd is encrypted with passphrase + key, and this key is in a usb stick (a different one form the other two already tried). The USB stick is not working to, and I also tried a USB Western Digital 500GB disk, no luck either! So no usb support basically... dmesg output after connecting the device: xhci_do_comand: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) usbgen0.2: Unknown at usbus0 (disconnected) usb_reattach_port: could not allocate new device Also note that usbus0 is a 3.0 as dmesg shows after boot: usbus0: waiting for BIOS to give up control usbus0 on xhci0 usbus0: 5.0Gpbs Super Speed USB v 3.0 So I guess this is indeed a problem in the 10.0-current kernel, not sure what it could be or what more can I do to debug though... Please advice, Hmm. Can you please try with a USB 2.0 port on the laptop? (Hopefully it has at least one non-USB-3.0 port...) Glen ___ 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: another external compiler topic
On Wed, Jun 05, 2013 at 08:53:14PM +0200, d...@gmx.com wrote: For the diagnosis of an error related to external compilers, I'll post full setup information. My first reaction is that your configuration is so far beyond anything that is actually documented as working you're going to be mostly on your own. That said, a few hopefully helpful comments below. First off I assume that since you posted to freebsd-current@ that you are running the latest head. Compiler version string: clang version 3.4 (trunk 182723). Installed system revision: 251046. Checked out source tree revision: 251352. The following 2 configuration files were used to build the installed system, as well as the new system. (However, see the compiler note later on.) === make.conf begins === CPUTYPE=native KERNCONF=MYCONF COMPILER_TYPE=clang CROSS_COMPILER_PREFIX= WITHOUT_FORMAT_EXTENSIONS=1 CC=/path/to/clang CPP=/path/to/clang-cpp CXX=/path/to/clang++ NO_CLEAN=1 NO_KERNELCLEAN=1 NO_MODULES=1 MALLOC_PRODUCTION=1 === make.conf ends === Setting CC, CPP, and CXX except in the environment isn't supported and can't work for cross build cases. It looks like your avoiding those cases (but more on your wrapper script later), but this does put you in uncharted land. === src.conf begins === WITHOUT_ACCT=1 WITHOUT_ACPI=1 WITHOUT_AMD=1 WITHOUT_APM=1 WITHOUT_AT=1 WITHOUT_ATF=1 WITHOUT_ATM=1 WITHOUT_AUDIT=1 WITHOUT_AUTHPF=1 WITHOUT_BIND=1 WITHOUT_BLUETOOTH=1 WITHOUT_BSNMP=1 WITHOUT_CALENDAR=1 WITHOUT_CDDL=1 WITHOUT_CLANG=1 WITHOUT_CLANG_IS_CC=1 WITHOUT_CTM=1 WITHOUT_CVS=1 WITHOUT_DICT=1 WITHOUT_ED_CRYPTO=1 WITHOUT_FDT=1 WITHOUT_FLOPPY=1 WITHOUT_FREEBSD_UPDATE=1 WITHOUT_GAMES=1 WITHOUT_GCC=1 WITHOUT_GCOV=1 WITHOUT_GDB=1 WITHOUT_GPIB=1 WITHOUT_GPIO=1 WITHOUT_HESIOD=1 WITHOUT_HTML=1 WITHOUT_INET6=1 WITHOUT_INFO=1 # [1] WITHOUT_IPFILTER=1 WITHOUT_IPFW=1 WITHOUT_IPX=1 WITHOUT_JAIL=1 WITHOUT_KDUMP=1 WITHOUT_KVM=1 WITHOUT_LDNS=1 WITHOUT_LEGACY_CONSOLE=1 WITHOUT_LOCATE=1 WITHOUT_LPR=1 WITHOUT_MAIL=1 WITHOUT_NDIS=1 WITHOUT_NETGRAPH=1 WITHOUT_NLS=1 WITHOUT_NLS_CATALOGS=1 WITHOUT_NTP=1 WITHOUT_PC_SYSINSTALL=1 WITHOUT_PF=1 WITHOUT_PKGTOOLS=1 WITHOUT_PMC=1 WITHOUT_PORTSNAP=1 WITHOUT_PPP=1 WITHOUT_PROFILE=1 WITHOUT_QUOTAS=1 WITHOUT_RCMDS=1 WITHOUT_RCS=1 WITHOUT_RESCUE=1 WITHOUT_SENDMAIL=1 WITHOUT_SHAREDOCS=1 WITHOUT_SYSINSTALL=1 WITHOUT_TELNET=1 WITHOUT_WIRELESS=1 WITHOUT_WPA_SUPPLICANT_EAPOL=1 WITH_BSD_GREP=1 WITH_BSD_PATCH=1 === src.conf ends === I see that WITHOUT_KERBEROS is not set here. Was it ever? Migration from a WITHOUT_KERBEROS system to a WITH_KERBEROS system is known to be broken which might explain your breakage in the libkrb5 build. For the interested reader, regarding # [1]: === /usr/bin/makeinfo begins === B= for i in $@ ; do if test -n $B ; then echo fuck this shit $i exit 0 fi if test $i = -o ; then B=1 fi done === /usr/bin/makeinfo ends === The following are output log snippets. (Snippet 2 contains an error that follows snippet 1; key term: parallel builds (most likely).) === `make buildworld` snippet 1 begins === building shared library libkadm5srv.so.11 === kerberos5/lib/libkafs5 (all) /i/a/clang -O2 -pipe -march=native -I/usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs -I/usr/src/kerberos5/li b/libkafs5/../../../crypto/heimdal/lib/krb5 -I/usr/obj/usr/src/kerberos5/lib/libkafs5/../libkrb5/ -I/usr/src/kerberos5/lib/li bkafs5/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libkafs5/../../include -std=gnu99 -Qunused-ar guments -fstack-protector -c /usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/afssys.c -o afssys.o In file included from /usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/afssys.c:34: In file included from /usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/kafs/kafs_locl.h:99: /usr/src/kerberos5/lib/libkafs5/../../../crypto/heimdal/lib/krb5/krb5-v4compat.h:39:10: fatal error: 'krb_err.h' file not found === `make buildworld` snippet 1 ends === === `make buildworld` snippet 2 begins === === kerberos5/lib/libkafs5 (install) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libkafs5.a /usr/obj/usr/src/tmp/usr/lib install: libkafs5.a: No such file or directory === `make buildworld` snippet 2 ends === When building the system that is currently installed, the following compiler was used: === /path/to/clang begins === #!/bin/sh /path/to/real/clang $@ || /path/to/real/clang --sysroot=/usr/obj/usr/src/tmp $@ === /path/to/clang ends === This has got to corrupt your build. I can't imagine anything staying working for long given that many translation units will compile with the system headers and then get linked to something compiled with the headers
Re: another external compiler topic
On 06/05/2013 21:31, Brooks Davis wrote:
My first reaction is that your configuration is so far beyond anything
that is actually documented as working you're going to be mostly on your
own.
Why?
First off I assume that since you posted to freebsd-current@ that you
are running the latest head.
Yes:
On Wed, Jun 05, 2013 at 08:53:14PM +0200, d...@gmx.com wrote:
Installed system revision: 251046.
Checked out source tree revision: 251352.
Setting CC, CPP, and CXX except in the environment isn't supported and
can't work for cross build cases. It looks like your avoiding those
cases (but more on your wrapper script later), but this does put you in
uncharted land.
Now compiling with CC, CPP and CXX only in the environment (and XCC, XCPP and
XCXX in make.conf).
I see that WITHOUT_KERBEROS is not set here. Was it ever? Migration
from a WITHOUT_KERBEROS system to a WITH_KERBEROS system is known to be
broken which might explain your breakage in the libkrb5 build.
Yes, WITHOUT_KERBEROS was set once in the past, but that was only so multiple
re-buildworld and re-installworld iterations ago.
When building the system that is currently installed, the following compiler
was used:
=== /path/to/clang begins ===
#!/bin/sh
/path/to/real/clang $@ || /path/to/real/clang --sysroot=/usr/obj/usr/src/tmp
$@
=== /path/to/clang ends ===
This has got to corrupt your build. I can't imagine anything staying
working for long given that many translation units will compile with
the system headers and then get linked to something compiled with the
headers from the source tree.
I forgot to mention that after re-buildworld-ing and re-installworld-ing with
the script, I redid the whole process again without the script (at which point
the sysroot argument was not required anymore, until the next header update).
Also, the following patch was applied to the source tree:
=== diff begins ===
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 251352)
+++ Makefile.inc1 (working copy)
@@ -722,7 +722,7 @@
ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep id install ${_install-info} \
ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp dd
#
# distributeworld
Index: usr.bin/xlint/llib/Makefile
===
--- usr.bin/xlint/llib/Makefile (revision 251352)
+++ usr.bin/xlint/llib/Makefile (working copy)
@@ -9,9 +9,9 @@
CLEANFILES+= ${LIBS}
llib-lposix.ln: llib-lposix
- ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
llib-lstdc.ln: llib-lstdc
- ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
.include bsd.prog.mk
=== diff ends ===
What do these patches work around?
The 1st hunk works around an installkernel issue: in some cases (unknown, but seemingly related to
header updates), installkernel seems to involve some compiling, cping,
btxlding, etc..
Without the 2nd hunk, the lint program would call cc, which does not exist
(ie., there is no /usr/bin/cc, but there is a ${CC}).
___
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: another external compiler topic
On Wed, Jun 05, 2013 at 10:46:01PM +0200, d...@gmx.com wrote:
On 06/05/2013 21:31, Brooks Davis wrote:
My first reaction is that your configuration is so far beyond anything
that is actually documented as working you're going to be mostly on your
own.
Why?
We can not possibly support all of the effectively infinite numbers of
knobs and switch you can set in the build process. If you want to veer
far outside the lines of well documented routes, it's up to you to find
and fix problems.
First off I assume that since you posted to freebsd-current@ that you
are running the latest head.
Yes:
On Wed, Jun 05, 2013 at 08:53:14PM +0200, d...@gmx.com wrote:
Installed system revision: 251046.
Checked out source tree revision: 251352.
Setting CC, CPP, and CXX except in the environment isn't supported and
can't work for cross build cases. It looks like your avoiding those
cases (but more on your wrapper script later), but this does put you in
uncharted land.
Now compiling with CC, CPP and CXX only in the environment (and XCC, XCPP and
XCXX in make.conf).
If you XCC, XCPP, and XCXX you may not need CC, CPP, and CXX at all,
though your environment is weird enough I won't assert that.
I see that WITHOUT_KERBEROS is not set here. Was it ever? Migration
from a WITHOUT_KERBEROS system to a WITH_KERBEROS system is known to be
broken which might explain your breakage in the libkrb5 build.
Yes, WITHOUT_KERBEROS was set once in the past, but that was only so multiple
re-buildworld and re-installworld iterations ago.
I've not experienced the kerberos failures so I'm not sure if this is
one or not. I suspect there is another error further up in your output,
but it's hard to say. If this is a parallel build there have been
reports of kerberos build failures with high levels of parallelism. It
may be that something you've disabled results in the presumed makefile
bug being easier to trigger.
When building the system that is currently installed, the following
compiler was used:
=== /path/to/clang begins ===
#!/bin/sh
/path/to/real/clang $@ || /path/to/real/clang
--sysroot=/usr/obj/usr/src/tmp $@
=== /path/to/clang ends ===
This has got to corrupt your build. I can't imagine anything staying
working for long given that many translation units will compile with
the system headers and then get linked to something compiled with the
headers from the source tree.
I forgot to mention that after re-buildworld-ing and re-installworld-ing with
the script, I redid the whole process again without the script (at which
point the sysroot argument was not required anymore, until the next header
update).
I guess that could work, but it still sounds like a recipe for disaster.
Also, the following patch was applied to the source tree:
=== diff begins ===
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 251352)
+++ Makefile.inc1 (working copy)
@@ -722,7 +722,7 @@
ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep id install ${_install-info} \
ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp dd
#
# distributeworld
Index: usr.bin/xlint/llib/Makefile
===
--- usr.bin/xlint/llib/Makefile(revision 251352)
+++ usr.bin/xlint/llib/Makefile(working copy)
@@ -9,9 +9,9 @@
CLEANFILES+= ${LIBS}
llib-lposix.ln: llib-lposix
- ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
llib-lstdc.ln: llib-lstdc
- ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
.include bsd.prog.mk
=== diff ends ===
What do these patches work around?
The 1st hunk works around an installkernel issue: in some cases (unknown, but
seemingly related to header updates), installkernel seems to involve some
compiling, cping, btxlding, etc..
Hmm, that seems weird. I've never seen that.
Without the 2nd hunk, the lint program would call cc, which does not exist
(ie., there is no /usr/bin/cc, but there is a ${CC}).
This sounds like a bug.
-- Brooks
pgpliWs_Lzy1i.pgp
Description: PGP signature
Re: another external compiler topic
On 06/05/2013 23:20, Brooks Davis wrote:
On Wed, Jun 05, 2013 at 10:46:01PM +0200, d...@gmx.com wrote:
Now compiling with CC, CPP and CXX only in the environment (and XCC, XCPP and
XCXX in make.conf).
Success!
If you XCC, XCPP, and XCXX you may not need CC, CPP, and CXX at all,
though your environment is weird enough I won't assert that.
There is no cc (/usr/bin/cc), so some form of CC is required.
Also, the following patch was applied to the source tree:
=== diff begins ===
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 251352)
+++ Makefile.inc1 (working copy)
@@ -722,7 +722,7 @@
ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep id install ${_install-info} \
ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp dd
#
# distributeworld
Index: usr.bin/xlint/llib/Makefile
===
--- usr.bin/xlint/llib/Makefile (revision 251352)
+++ usr.bin/xlint/llib/Makefile (working copy)
@@ -9,9 +9,9 @@
CLEANFILES+= ${LIBS}
llib-lposix.ln: llib-lposix
- ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
llib-lstdc.ln: llib-lstdc
- ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
+ CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
.include bsd.prog.mk
=== diff ends ===
What do these patches work around?
The 1st hunk works around an installkernel issue: in some cases (unknown, but seemingly related to
header updates), installkernel seems to involve some compiling, cping,
btxlding, etc..
Hmm, that seems weird. I've never seen that.
Actually, installworld, not installkernel.
Without the 2nd hunk, the lint program would call cc, which does not exist
(ie., there is no /usr/bin/cc, but there is a ${CC}).
This sounds like a bug.
Well, now, with a CC environment variable, the hunk is no longer required for me. But
then again, the lint program calls cc if there is no CC environment variable,
such as when CC is set only in make.conf.
According to https://wiki.freebsd.org/ExternalToolchain:
To use XCC, you must not set any of the variables that can be overridden by X*
variables in /etc/make.conf or /etc/src.conf as Makefile.inc1 will be unable to
change them.
Why? In my case, CC should always be /path/to/clang (however, CFLAGS should contain
--sysroot=/usr/obj/..., when appropriate).
___
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: another external compiler topic
On Thu, Jun 06, 2013 at 12:16:28AM +0200, d...@gmx.com wrote:
On 06/05/2013 23:20, Brooks Davis wrote:
On Wed, Jun 05, 2013 at 10:46:01PM +0200, d...@gmx.com wrote:
Now compiling with CC, CPP and CXX only in the environment (and XCC, XCPP
and XCXX in make.conf).
Success!
If you XCC, XCPP, and XCXX you may not need CC, CPP, and CXX at all,
though your environment is weird enough I won't assert that.
There is no cc (/usr/bin/cc), so some form of CC is required.
Makes sense.
Also, the following patch was applied to the source tree:
=== diff begins ===
Index: Makefile.inc1
===
--- Makefile.inc1(revision 251352)
+++ Makefile.inc1(working copy)
@@ -722,7 +722,7 @@
ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep id install ${_install-info} \
ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
-rm sed sh sysctl test true uname wc ${_zoneinfo}
+rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp
dd
#
# distributeworld
Index: usr.bin/xlint/llib/Makefile
===
--- usr.bin/xlint/llib/Makefile (revision 251352)
+++ usr.bin/xlint/llib/Makefile (working copy)
@@ -9,9 +9,9 @@
CLEANFILES+= ${LIBS}
llib-lposix.ln: llib-lposix
-${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
+CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
llib-lstdc.ln: llib-lstdc
-${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
+CC=${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
.include bsd.prog.mk
=== diff ends ===
What do these patches work around?
The 1st hunk works around an installkernel issue: in some cases (unknown,
but seemingly related to header updates), installkernel seems to involve
some compiling, cping, btxlding, etc..
Hmm, that seems weird. I've never seen that.
Actually, installworld, not installkernel.
That should never happen AFACT.
Without the 2nd hunk, the lint program would call cc, which does not
exist (ie., there is no /usr/bin/cc, but there is a ${CC}).
This sounds like a bug.
Well, now, with a CC environment variable, the hunk is no longer required for
me. But then again, the lint program calls cc if there is no CC environment
variable, such as when CC is set only in make.conf.
As I said, this sounds like a legitimate makefile bug.
According to https://wiki.freebsd.org/ExternalToolchain:
To use XCC, you must not set any of the variables that can be overridden by
X* variables in /etc/make.conf or /etc/src.conf as Makefile.inc1 will be
unable to change them.
Why? In my case, CC should always be /path/to/clang (however, CFLAGS should
contain --sysroot=/usr/obj/..., when appropriate).
It only works in your case because of your wrapper script and the fact
that you aren't cross compiling. The XCC code needs to be able to set
CC to include --sysroot and -B and -target. Doing it via CFLAGS proved
to be too complex with the current build infrastructure.
-- Brooks
pgp4y4wwdFT4F.pgp
Description: PGP signature
Can't compile lxpanel
I'm running 10.0-CORRENT on amd64. Ports and source are both up to date. When I try to compile x11/lxpanel I get this: -- gmake[4]: Entering directory `/usr/ports/x11/lxpanel/work/lxpanel-0.5.12/ src/plugins/volume' CC volume_la-volume.lo volume.c:193:20: error: non-void function 'on_button_press' should return a value [-Wreturn-type] if (! vol_spin) return; ^ volume.c:196:26: error: non-void function 'on_button_press' should return a value [-Wreturn-type] if (! vol_adjustment) return; ^ volume.c:217:19: error: non-void function 'on_button_press' should return a value [-Wreturn-type] if (! vol_spin) return; ^ volume.c:220:25: error: non-void function 'on_button_press' should return a value [-Wreturn-type] if (! vol_adjustment) return; ^ volume.c:286:21: error: non-void function 'volume_constructor' should return a value [-Wreturn-type] if (! vol_spin) return; ^ volume.c:289:27: error: non-void function 'volume_constructor' should return a value [-Wreturn-type] if (! vol_adjustment) return; ^ volume.c:309:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] PLUGINCLASS_VERSIONING, ^ ../../../src/plugin.h:35:5: note: expanded from macro 'PLUGINCLASS_VERSIONING' structure_size : sizeof(PluginClass), \ ^ volume.c:309:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] ../../../src/plugin.h:36:5: note: expanded from macro 'PLUGINCLASS_VERSIONING' structure_version : PLUGINCLASS_VERSION ^ volume.c:311:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] type : volume, ^~ .type = volume.c:312:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] name : N_(Volume Control), ^~ .name = volume.c:313:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] version: 1.0, ^~~~ .version = volume.c:314:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] description : Display and control volume, ^ .description = volume.c:316:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] constructor : volume_constructor, ^ .constructor = volume.c:317:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] destructor : volume_destructor, ^ .destructor = volume.c:318:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] config : NULL, ^~~~ .config = volume.c:319:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] save : NULL ^~ .save = 10 warnings and 6 errors generated. gmake[4]: *** [volume_la-volume.lo] Error 1 gmake[4]: Leaving directory `/usr/ports/x11/lxpanel/work/lxpanel-0.5.12/ src/plugins/volume' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/x11/lxpanel/work/lxpanel-0.5.12/ src/plugins' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/x11/lxpanel/work/lxpanel-0.5.12/ src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11/lxpanel/work/lxpanel-0.5.12' gmake: *** [all] Error 2 *** Error code 1 Stop. make: stopped in /usr/ports/x11/lxpanel *** Error code 1 Stop. make: stopped in /usr/ports/x11/lxpanel -- Is there anything I can do? ___ 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
