Clang now builds world and kernel, on i386 and amd64
Hi,
As of r212979, you should now be able to build world and kernel on i386
and amd64 with clang, without any additional patches!
To do so, make sure you have updated your installed world to at least
r212904 (which has the most recently imported clang/llvm snapshot), and
put the following in /etc/src.conf:
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Both world and kernel can also be installed, and should run properly,
but please make sure you have a way to revert if anything unexpected
happens. :) Alternatively, just install into a chroot to try it out
from there.
Some additional information can be found on this wiki page:
http://wiki.freebsd.org/BuildingFreeBSDWithClang
Thanks to all the people that made this possible, especially Roman
Divacky, Ed Schouten, Rui Paulo, and of course the clang/llvm
developers.
___
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: RFT: if_ath HAL refactoring
On Wednesday, September 22, 2010 06:04:49 PseudoCylon wrote: > - Original Message > > > From: Adrian Chadd > > To: PseudoCylon > > Cc: freebsd-current@freebsd.org > > Sent: Tue, September 21, 2010 7:04:37 AM > > Subject: Re: RFT: if_ath HAL refactoring > > > > On 21 September 2010 11:58, PseudoCylon wrote: > > > Just in case anyone wonders, I've added 11n support to run(4) (USB > > > NIC). http://gitorious.org/run/run/trees/11n_beta2 > > > > > > It still has some issues, > > > > > > * doesn't work well with atheros chips > > > > > > * HT + AP + bridge = Tx may stall (seems OK with nat) > > > > > > So, use it at your own discretion. > > > > Want to put together a patch? > > sure! > > > Does it introduce issues in the non-11n case? > > No, only in 11n mode. > > What I have found so far is that Ralink's driver checks MAC address of > other end and identify atheros chip by oui. Then, sets special prot mode > for it. Does this ring a bell? Are your sure that this is based on the actual MAC addresses? Atheros drivers tend to announce additional capabilities in beacons and probe responses. > Has node lock in ieee80211_node_timeout() cased dead lock in HT + AP + > bridge? I'm not aware of any issues there, though, I'm not very familiar with HT use cases. -- Bernhard ___ 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"
Rollout plan for new version of man/manpath/whatis/apropos
I'm to the point where I'm ready to the commit the code, but I wanted to layout a plan for the conversion and ask for input to make sure I didn't miss anything. 1. Commit the code located at http://people.freebsd.org/~gordon/man.shar into src/usr.bin/man (pending mentor review). 2. Unhook src/gnu/usr.bin/man from the build. 3. Unhook src/etc/manpath.config from the build (in src/etc/Makefile). 4. Add entry to src/ObsoleteFiles.inc to remove etc/manpath.config. 5. Hook src/usr.bin/man to the build. 6. Alter src/etc/mtree/BSD.local.mtree to include an entry for LOCALBASE/etc/man.d 7. Add entry into src/UPDATING about the change over deprecating /etc/manpath.config 8. Bump __FreeBSD_version in src/sys/sys/param.h 9. Document version bump in doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 10. Contact following ports owners to use new include system rather than manipulating /etc/manpath.config directly: japanese/man lang/perl5.8 lang/perl5.10 lang/perl5.12 11. Contact following ports owners to use new include system rather than displaying a message in pkg-message: graphics/tcm lang/erlang lang/metaocaml 12. Contact following ports owners to change their scripts as needed to accommodate the fact there isn't a manpath.config anymore: ports-mgmt/tinderbox x11/xorg-libraries I think that's everything. Am I missing anything? Thanks, Gordon ___ 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: RFT: if_ath HAL refactoring
- Original Message > From: Adrian Chadd > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Tue, September 21, 2010 7:04:37 AM > Subject: Re: RFT: if_ath HAL refactoring > > On 21 September 2010 11:58, PseudoCylon wrote: > > > Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). > > http://gitorious.org/run/run/trees/11n_beta2 > > > > It still has some issues, > > * doesn't work well with atheros chips > > * HT + AP + bridge = Tx may stall (seems OK with nat) > > So, use it at your own discretion. > > Want to put together a patch? sure! > > Does it introduce issues in the non-11n case? No, only in 11n mode. What I have found so far is that Ralink's driver checks MAC address of other end and identify atheros chip by oui. Then, sets special prot mode for it. Does this ring a bell? Has node lock in ieee80211_node_timeout() cased dead lock in HT + AP + bridge? AK ___ 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 arm/arm
TB --- 2010-09-21 14:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-21 14:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-09-21 14:20:00 - cleaning the object tree TB --- 2010-09-21 14:20:45 - cvsupping the source tree TB --- 2010-09-21 14:20:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup5.freebsd.org /tinderbox/HEAD/arm/arm/supfile TB --- 2010-09-21 14:26:21 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-21 14:26:21 - ERROR: unable to cvsup the source tree TB --- 2010-09-21 14:26:21 - 1.34 user 45.49 system 381.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.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: RFT: if_ath HAL refactoring
On 21 September 2010 21:19, John Baldwin wrote: >> I've not idea right now whether there's an Atheros SoC with an >> AHB-attached wireless device and a PCI bus. In fact, that won't work >> at the present time because the device names would clash. > > Why would the device names clash? We have _lots_ of drivers with multiple bus > attachments that use the same name regardless of which bus they are on, and > making a bus attachment conditional on the bus being present is what every > other driver that desires this level of granularity does. Cool. Well, that's one less thing I have to worry about. :-) Thanks, Adrian ___ 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: Document EVFILT_FS and VQ_*
2010/9/21 John Baldwin : > On Tuesday, September 21, 2010 8:22:24 am Baptiste Daroussin wrote: >> Hi, >> >> For a projects I needed to use EVFILT_FS and saw that it hasn't been >> documented >> so here is a patch to document it http://planet.etoilebsd.net/kqueue.2.diff >> >> It is based on the commit message for the implementation of EVFILT_FS, sorry >> I >> don't know how to better document it >> (http://lists.freebsd.org/pipermail/cvs-src/2005-September/052288.html) > > Hmm, the code for this seems quite broken. For example, when an NFS mount is > marked up, it posts an event saying it is down. Right now when the user gets > an EVFILT_FS event, the info in the event contains a mask of states that have > changed, but the code would still need to issue a VFS_CTL_QUERY sysctl to get > the actual state. It would be more useful if the kevent could return two > values: 1) would be a bitmask of changed flags, and 2) would be the current > state of the vfs query flags. Perhaps 2) could be implemented in kn_data, > but we would need to change the kernel to keep the current state of the > vfs query flags in 'struct mount' (this could be done in vfs_event_signal()). > Doing so would also allow VFS_CTL_QUERY to be implemented generically. > >> While using it I also discover that VQ_MOUNT, VQ_UMOUNT, VQ_NOTRESP and >> VQ_NOTRESPLOCK are not documented either but I don't know where to document >> them. > > VFS_CTL_QUERY is not really documented either. For now I think you could > document all of this in kevent(2). At the very least, you should note that > for EVFILT_FS, the 'flags' field is a bitmask of changed flags that can be > queried via VFS_CTL_QUERY. If the code is changed to provide the current > flags in 'data', then you could just document the flags explicitly and not > bother mentioning VFS_CTL_QUERY. > *Ouch* I'm far from understanding everything, I think I won't be able to document all that without a real comprehension of it. At the begining I just wanted to point out that some parts wasn't documented, and try to document what I could :) regards, Bapt ___ 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: RFT: if_ath HAL refactoring
On Monday, September 20, 2010 10:06:53 am Adrian Chadd wrote: > On 20 September 2010 21:25, John Baldwin wrote: > > > Why not include this iff both 'device ath' and 'device pci' are included? > > That is what is normally done for bus-specific attachments. > > I've not idea right now whether there's an Atheros SoC with an > AHB-attached wireless device and a PCI bus. In fact, that won't work > at the present time because the device names would clash. Why would the device names clash? We have _lots_ of drivers with multiple bus attachments that use the same name regardless of which bus they are on, and making a bus attachment conditional on the bus being present is what every other driver that desires this level of granularity does. -- 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: Document EVFILT_FS and VQ_*
On Tuesday, September 21, 2010 8:22:24 am Baptiste Daroussin wrote: > Hi, > > For a projects I needed to use EVFILT_FS and saw that it hasn't been > documented > so here is a patch to document it http://planet.etoilebsd.net/kqueue.2.diff > > It is based on the commit message for the implementation of EVFILT_FS, sorry I > don't know how to better document it > (http://lists.freebsd.org/pipermail/cvs-src/2005-September/052288.html) Hmm, the code for this seems quite broken. For example, when an NFS mount is marked up, it posts an event saying it is down. Right now when the user gets an EVFILT_FS event, the info in the event contains a mask of states that have changed, but the code would still need to issue a VFS_CTL_QUERY sysctl to get the actual state. It would be more useful if the kevent could return two values: 1) would be a bitmask of changed flags, and 2) would be the current state of the vfs query flags. Perhaps 2) could be implemented in kn_data, but we would need to change the kernel to keep the current state of the vfs query flags in 'struct mount' (this could be done in vfs_event_signal()). Doing so would also allow VFS_CTL_QUERY to be implemented generically. > While using it I also discover that VQ_MOUNT, VQ_UMOUNT, VQ_NOTRESP and > VQ_NOTRESPLOCK are not documented either but I don't know where to document > them. VFS_CTL_QUERY is not really documented either. For now I think you could document all of this in kevent(2). At the very least, you should note that for EVFILT_FS, the 'flags' field is a bitmask of changed flags that can be queried via VFS_CTL_QUERY. If the code is changed to provide the current flags in 'data', then you could just document the flags explicitly and not bother mentioning VFS_CTL_QUERY. -- 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: Port won't build because of installed conflict
On Tue, Sep 21, 2010 at 12:37:29PM +0200, Angelo Turetta wrote: > On 20:59, Ian FREISLICH wrote: > >Hi > > > >[mini] /usr/ports/www/firefox # make > > > try > make DISABLE_CONFLICTS=YES > > or use ports-mgmt/portmaster > portmaster -o www/firefox firefox-3.5.13,1 This one alone will not work. In the UPDATING entry dated 20100207 it is clearly stated that removing firefox 3.5 before building FF 3.6 is required. He could try disabling conflicts, but this could lead to a corrupt FF 3.6 build. I think that the conflict has been put there for good, so building a package in a jail, virtual machine, other machine or an emulator looks like the only safe solution. Anyway if someone wants to try, maybe disabling conflcts is a perfectly safe way. But one cannot know for sure until he tries. -- Guido Falsi ___ 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: RFT: if_ath HAL refactoring
On 21 September 2010 11:58, PseudoCylon wrote: > Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). > http://gitorious.org/run/run/trees/11n_beta2 > > It still has some issues, > * doesn't work well with atheros chips > * HT + AP + bridge = Tx may stall (seems OK with nat) > So, use it at your own discretion. Want to put together a patch? Does it introduce issues in the non-11n case? Having more 11n options for FreeBSD-9.0 would be really nice. :) Adrian ___ 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"
Document EVFILT_FS and VQ_*
Hi, For a projects I needed to use EVFILT_FS and saw that it hasn't been documented so here is a patch to document it http://planet.etoilebsd.net/kqueue.2.diff It is based on the commit message for the implementation of EVFILT_FS, sorry I don't know how to better document it (http://lists.freebsd.org/pipermail/cvs-src/2005-September/052288.html) While using it I also discover that VQ_MOUNT, VQ_UMOUNT, VQ_NOTRESP and VQ_NOTRESPLOCK are not documented either but I don't know where to document them. It would be great to see all of this documented, it would be useful at least for me :) regards, Bapt pgph5mGJEoitY.pgp Description: PGP signature
Re: Port won't build because of installed conflict
On 20:59, Ian FREISLICH wrote: Hi [mini] /usr/ports/www/firefox # make try make DISABLE_CONFLICTS=YES or use ports-mgmt/portmaster portmaster -o www/firefox firefox-3.5.13,1 Ciao, Angelo. ___ 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: Port won't build because of installed conflict
On Tue, Sep 21, 2010 at 10:06:34AM +0200, Ian FREISLICH wrote: > Hi > > [mini] /usr/ports/www/firefox # make > > ===> firefox-3.6.10,1 conflicts with installed package(s): > firefox-3.5.13,1 > > They install files into the same place. > Please remove them first with pkg_delete(1). > *** Error code 1 > > Stop in /usr/ports/www/firefox. > *** Error code 1 > > But I don't want to be without the browser while I'm building the > new one. Is there a reason why this conflict isn't checked at > install time rather than build time? I think this happens because in your situation firefox 3.6 would end up linking against FF 3.5 libraries. Perhaps you could setup a build environment in a jail, make a package for it and then just remove FF 3.5 and intall the 3.6 package. -- Guido Falsi ___ 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: One-shot timer broken on Xen
Bruce Cran wrote: > On Sat, 18 Sep 2010 19:42:45 +0300 > Alexander Motin wrote: >> Bruce Cran wrote: >>> I built a new kernel from HEAD on my Xen domU today and found that >>> it hung after the following messages: >>> >>> smist0: on cpu0 >>> device_attach: smist0 attach returned 6 >>> Device configuration finished. >>> procfs registered >>> Timecounter "TSC" frequency 2000118476 Hz quality 800 >>> lapic: Divisor 2, Frequency 50001605 Hz >>> >>> Setting kern.eventtimer.periodic to 1 allows the system to boot. >> This doesn't tells much. What event timers found by the system there >> and what of them was used? > > Sorry - here's the kern.eventtimer output: > > kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) > kern.eventtimer.et.LAPIC.flags: 15 > kern.eventtimer.et.LAPIC.frequency: 50001856 > kern.eventtimer.et.LAPIC.quality: 400 > kern.eventtimer.et.i8254.flags: 1 > kern.eventtimer.et.i8254.frequency: 1193182 > kern.eventtimer.et.i8254.quality: 100 > kern.eventtimer.et.RTC.flags: 17 > kern.eventtimer.et.RTC.frequency: 32768 > kern.eventtimer.et.RTC.quality: 0 > kern.eventtimer.periodic: 1 > kern.eventtimer.timer: LAPIC > kern.eventtimer.idletick: 0 > kern.eventtimer.singlemul: 4 While I have no idea what else could be wrong with one-shot mode there, could you try to update to SVN r212958 to make sure it is not related? That problem should not stop boot completely, but it could delay it for some time. -- Alexander Motin ___ 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"
Port won't build because of installed conflict
Hi [mini] /usr/ports/www/firefox # make ===> firefox-3.6.10,1 conflicts with installed package(s): firefox-3.5.13,1 They install files into the same place. Please remove them first with pkg_delete(1). *** Error code 1 Stop in /usr/ports/www/firefox. *** Error code 1 But I don't want to be without the browser while I'm building the new one. Is there a reason why this conflict isn't checked at install time rather than build time? 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"
