Re: [panic] 10-CURRENT r239865: General protection fault (sysctl)
On Tue, Sep 11, 2012 at 6:32 PM, Glen Barber wrote: >> >> I'd blame this one: >> >> http://lists.freebsd.org/pipermail/svn-src-head/2012-September/040236.html >> > > Yes, reverting that commit allows the system to boot. > Hi, Same problem on my side (under Virtualbox or on an IBM 3550 M2). Regards, Olivier ___ 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] 10-CURRENT r239865: General protection fault (sysctl)
Am 09/12/12 09:30, schrieb Olivier Cochard-Labbé: > On Tue, Sep 11, 2012 at 6:32 PM, Glen Barber wrote: >>> >>> I'd blame this one: >>> >>> http://lists.freebsd.org/pipermail/svn-src-head/2012-September/040236.html >>> >> >> Yes, reverting that commit allows the system to boot. >> > > Hi, > > Same problem on my side (under Virtualbox or on an IBM 3550 M2). > > Regards, > > Olivier That should be solved by now (at least with r240369. I ran into the same problem on several FreeBSD 10.0-CURRENT boxes. Oliver signature.asc Description: OpenPGP digital signature
Re: [panic] 10-CURRENT r239865: General protection fault (sysctl)
on 12/09/2012 10:30 Olivier Cochard-Labbé said the following: > On Tue, Sep 11, 2012 at 6:32 PM, Glen Barber wrote: >>> >>> I'd blame this one: >>> >>> http://lists.freebsd.org/pipermail/svn-src-head/2012-September/040236.html >>> >> >> Yes, reverting that commit allows the system to boot. >> > > Hi, > > Same problem on my side (under Virtualbox or on an IBM 3550 M2). This should be fixed already. Sorry for the breakage and for not writing about the fix to this thread. -- Andriy Gapon ___ 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"
Scheduler KTR traces for 4 variants (ULE, 4BSD)x(PREEMPTION, NOPREEMPTION) on small hardware (net5501) with network traffic (Was: vr(4) troubles for AMD Geode CS5536 chipset)
Hello, Adrian. You wrote 6 сентября 2012 г., 22:12:04: AC> On 6 September 2012 11:11, Lev Serebryakov wrote: >> Hello, Adrian. >> You wrote 6 сентября 2012 г., 22:07:08: >> >> AC> Oh don't worry about polling just yet. I just want to see what >> AC> preempt/no-preempt does with ULE and 4BSD on these little single-CPU >> AC> platforms. >> Ok, I'll do it. Should I post 4 outputs from ktrdump? Again, I don't >> understand how to interpret these data by myself. AC> Yes. Here: http://lev.serebryakov.spb.ru/ktrs/ Tarball with all 4 outputs and all configs are placed. Setup and results are described in "readme.txt". Results are strange: no visible WiFi slowdown but wired traffic slowdown now and bad freezes in all combinations but 4BSD + PREEMPTION _enabled_. -- // Black Lion AKA Lev Serebryakov ___ 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: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote: > At the moment the ports maintainers don't give much about if their ports > build with CLANG or not because they're not forced to. I think this is a mis-representation. Adding the requirement "your ports must work on clang" is adding an ex-post-facto requirement. This creates the following matrix of what we are implicitly asking maintainers to do: (FreeBSD 7|8|9|10) * (amd64|arm|i386|powerpc|sparc64) * (base gcc|base clang) It is completely insane to expect anyone to be able to test in all of those environments, or even a tiny subset of them. This isn't what most people sign up for when they sign up to maintain ports. > Those who don't run CURRENT won't notice, but those who do will have to > get their butts up and fix the ports I think it's foolish to assume that maintainres don't have their butts in gear as it is. Please note, we have nearly 1300 PRs, hundreds of ports with build errors and/or PRs, and hundreds that fail on -current only. I try to advertise all these things the best I know how. Adding the hundreds that fail on -clang only and then blaming the maintainers is simply going to be counter-productive. mcl ___ 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: Clang as default compiler November 4th
On 12 Sep 2012, at 10:15, Mark Linimon wrote: > On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote: >> At the moment the ports maintainers don't give much about if their ports >> build with CLANG or not because they're not forced to. > > I think this is a mis-representation. > > Adding the requirement "your ports must work on clang" is adding an > ex-post-facto requirement. This creates the following matrix of what > we are implicitly asking maintainers to do: > > (FreeBSD 7|8|9|10) * (amd64|arm|i386|powerpc|sparc64) * (base gcc|base clang) > > It is completely insane to expect anyone to be able to test in all of those > environments, or even a tiny subset of them. This isn't what most people > sign up for when they sign up to maintain ports. > >> Those who don't run CURRENT won't notice, but those who do will have to >> get their butts up and fix the ports > > I think it's foolish to assume that maintainres don't have their butts in > gear as it is. Please note, we have nearly 1300 PRs, hundreds of ports with > build errors and/or PRs, and hundreds that fail on -current only. I try to > advertise all these things the best I know how. Adding the hundreds that > fail on -clang only and then blaming the maintainers is simply going to be > counter-productive. I'd also guess that FreeBSD ports is probably the biggest exposure clang has ever seen to 3rd party code. I can't think of any other project except maybe macports who try to run clang over some much 3rd party code and so FreeBSD ports is hitting all the bumps in the road that most people get to ignore. - Mark ___ 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: Clang as default compiler November 4th
On 09/11/2012 02:52 AM, Erik Cederstrand wrote: > So can we do a sweep on the ports tree and mark the 2232 ports with > USE_GCC=4.2 until they can actually build with clang? Unfortunately it isn't that simple. We already have a statistically significant number of ports that don't even compile with gcc 4.2.1. How many compilers do we expect the users to install? :) What we need to do is what I and others have been asking to do for years. We need to designate a modern version of gcc (no less than 4.6) as the official default ports compiler, and rework whatever is needed to support this. Fortunately, that goal is much more easily achieved than fixing ports to build and run with clang. (It's harder than it sounds because there are certain key libs that define some paths depending on what compiler they were built with, but still easier than dealing with clang in the short term.) Once that is done, the compiler in the base is an afterthought, and we can do away with gcc in the base altogether much more easily. Users who want to help support building ports with clang can continue to do so. Doug ___ 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: Clang as default compiler November 4th
On 09/11/2012 11:15 PM, Mark Linimon wrote: > On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote: >> At the moment the ports maintainers don't give much about if their ports >> build with CLANG or not because they're not forced to. > > I think this is a mis-representation. > > Adding the requirement "your ports must work on clang" is adding an > ex-post-facto requirement. This creates the following matrix of what > we are implicitly asking maintainers to do: > > (FreeBSD 7|8|9|10) * (amd64|arm|i386|powerpc|sparc64) * (base gcc|base clang) > > It is completely insane to expect anyone to be able to test in all of those > environments, or even a tiny subset of them. This isn't what most people > sign up for when they sign up to maintain ports. > >> Those who don't run CURRENT won't notice, but those who do will have to >> get their butts up and fix the ports > > I think it's foolish to assume that maintainres don't have their butts in > gear as it is. Please note, we have nearly 1300 PRs, hundreds of ports with > build errors and/or PRs, and hundreds that fail on -current only. I try to > advertise all these things the best I know how. Adding the hundreds that > fail on -clang only and then blaming the maintainers is simply going to be > counter-productive. Write the day on your calendars folks, I completely agree with what Mark said above. :) This is a big part of what I meant with some of my more colorful comments in my original post on this topic. Doug ___ 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: Clang as default compiler November 4th
Fwiw, I plan to fix this issue, but even if I didnt. This isnt a problem in clang rather than in llvm asm. So it can be easily worked around by CFLAGS+=-no-integrated-as. Roman On Tue, Sep 11, 2012 at 11:22:44PM +0200, Patrick Lamaiziere wrote: > Le Mon, 10 Sep 2012 16:12:07 -0500, > Brooks Davis a ?crit : > > Hello, > > > For the past several years we've been working towards migrating from > > GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD > > 10.0 with Clang as the default compiler on i386 and amd64 platforms. > > To this end, we will make WITH_CLANG_IS_CC the default on i386 and > > amd64 platforms on November 4th. > > Last time I've checked on 9.X [mid August, FreeBSD clang version 3.1 > (branches/release_31 156863) 20120523], Clang still produces invalid > code (some nopl (%eax)) for the AMD Geode LX (i586 CPU found on some > ALIX board or Soekris NET5501). I don't know if this is also a concern > with older CPU (Pentium 2/1) ? > > http://llvm.org/bugs/show_bug.cgi?id=11212 > http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028588.html > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/168253 > > > What does the mean to you? > > Well, I will not be able to run FreeBSD from scratch on my soekris :-) > > Best regards. > ___ > 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: Raspberry PI gets USB support [FreeBSD 10 current]
We tested kernel built by gonzo@, there working framebuffer, ue0, and USB2.0 devices (in theory, I didn't have those). But after some activity (like download few megabytes file) all is stuck with message usb device stalled This is getting 100% repeatedly, no matter if download goes to sd card, or to malloc-md-device. If (When) this will be fixed, then Rpi would be a candy, prepared to testing and more or less usable. I have in plans try it with xorg-framebuffer, and with directfb, while there's no video support. -- Regards, Alexander Yerenkow ___ 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"
nice-ing a service?
Hi, For whatever reason, I'd like to start services, from a properly formed rc.d script, configured via /etc/rc.conf, etc. with a custom "nice" value. Is there already support for this? signature.asc Description: OpenPGP digital signature
Re: nice-ing a service?
On Wed, Sep 12, 2012 at 11:31 AM, Ivan Voras wrote:
> Hi,
>
> For whatever reason, I'd like to start services, from a properly formed
> rc.d script, configured via /etc/rc.conf, etc. with a custom "nice"
> value. Is there already support for this?
>
rc.subr indicates you can use ${name}_nice for this purpose.
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: nice-ing a service?
On 12/09/2012 12:31, Ivan Voras wrote: > Hi, > > For whatever reason, I'd like to start services, from a properly formed > rc.d script, configured via /etc/rc.conf, etc. with a custom "nice" > value. Is there already support for this? ... nevermind, I found it's already there in rc.subr, just not documented in rc.conf(5). signature.asc Description: OpenPGP digital signature
Re: Clang as default compiler November 4th
Den 12/09/2012 kl. 11.29 skrev Doug Barton : > On 09/11/2012 02:52 AM, Erik Cederstrand wrote: >> So can we do a sweep on the ports tree and mark the 2232 ports with >> USE_GCC=4.2 until they can actually build with clang? > > Unfortunately it isn't that simple. We already have a statistically > significant number of ports that don't even compile with gcc 4.2.1. How > many compilers do we expect the users to install? :) If a port doesn't compile with the default compiler in base, I expect that port to add a build dependency on the compiler that it actually does compiles with. Of course, I hope to not have 6 different compilers installed on my system, but the list of build or runtime dependencies are at the discretion of the port (maintainer). As you (I think) said, we can't force port maintainers to patch their ports to support clang. So even today, we have a significant number of ports that don't compile with the default compiler (GCC 4.2.1). Aren't they broken already, in the sense that they fail to tell me, the user, which compiler I should use? Thanks, Erik___ 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"
Building world with clang ToT
Hi, Has anyone recently built FreeBSD10-current with clang on a FreeBSD9 amd64 system? I've bumped into a number of issues. Mainly, buildworld picks up the old system includes, which miss newly introduced symbols; same thing with libraries. I fixed that by pointing compiler and linker to /usr/obj/FreeBSD-HEAD/tmp/include and lib. Building stops in lib/libstand: /usr/home/emeewis/src/FreeBSD-HEAD/lib/libstand/i386/_setjmp.S:50:82: error: register %rbp is only available in 64-bit mode .text; .p2align 4,0x90; .globl _setjmp; .type _setjmp,@function; _setjmp:; pushq %rbp; movq %rsp,%rbp; call .mcount; popq %rbp; 9: Libstand is build in i386 mode, but includes machine/asm.h in _setjmp.S. Is there a way to force it to use i386/asm.h? I had a go with gcc, but I got the same results... -- Ed. ___ 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: Building world with clang ToT
On 2012-09-12 12:46, Edward Meewis wrote: Has anyone recently built FreeBSD10-current with clang on a FreeBSD9 amd64 system? I've bumped into a number of issues. Mainly, buildworld picks up the old system includes, which miss newly introduced symbols; same thing with libraries. I fixed that by pointing compiler and linker to /usr/obj/FreeBSD-HEAD/tmp/include and lib. Strange, it should not do that. How exactly did you "point compiler and linker"? What is your make.conf and/or src.conf? If had to hazard a guess based on this information alone, I would say you are assigning to CFLAGS somewhere, instead of using +=. Building stops in lib/libstand: /usr/home/emeewis/src/FreeBSD-HEAD/lib/libstand/i386/_setjmp.S:50:82: error: register %rbp is only available in 64-bit mode .text; .p2align 4,0x90; .globl _setjmp; .type _setjmp,@function; _setjmp:; pushq %rbp; movq %rsp,%rbp; call .mcount; popq %rbp; 9: Libstand is build in i386 mode, but includes machine/asm.h in _setjmp.S. Is there a way to force it to use i386/asm.h? I had a go with gcc, but I got the same results... There must be a certain setting on your system which causes this. Most likely, it is again using your existing system headers, instead of those in /usr/obj. ___ 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: Clang as default compiler November 4th
On 09/11/2012 05:03 AM, Steve Kargl wrote: > On Tue, Sep 11, 2012 at 04:10:13PM +0200, Dimitry Andric wrote: >> >> However, I think the majority of users can get by just fine using clang, >> right now. Doug Barton even confirmed in this thread that 80% of our >> ports already work with it! > > He stated that 80% build with clang. I doubt that he actually > tested the functionality of some 17000 ports. Correct. Also, users who actually are helping with testing clang for ports continue to report runtime problems, even with things that build fine. Doug ___ 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: Building world with clang ToT
Hi Dimitry,
On 12-09-12 13:09, Dimitry Andric wrote:
On 2012-09-12 12:46, Edward Meewis wrote:
Has anyone recently built FreeBSD10-current with clang on a FreeBSD9
amd64 system?
I've bumped into a number of issues. Mainly, buildworld picks up the old
system includes, which miss newly introduced symbols; same thing with
libraries. I fixed that by pointing compiler and linker to
/usr/obj/FreeBSD-HEAD/tmp/include and lib.
Strange, it should not do that. How exactly did you "point compiler and
linker"? What is your make.conf and/or src.conf?
If had to hazard a guess based on this information alone, I would say
you are assigning to CFLAGS somewhere, instead of using +=.
I added the following lines to each individual Makefile it stumbled on:
CFLAGS+= -I/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/include
LDADD+=-L/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/lib
or:
LDFLAGS+=-L/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/lib
I hope to find a better place to set those, but it will do for now.
Building stops in lib/libstand:
/usr/home/emeewis/src/FreeBSD-HEAD/lib/libstand/i386/_setjmp.S:50:82:
error: register %rbp is only available in 64-bit mode
.text; .p2align 4,0x90; .globl _setjmp; .type _setjmp,@function;
_setjmp:; pushq %rbp; movq %rsp,%rbp; call .mcount; popq %rbp; 9:
Libstand is build in i386 mode, but includes machine/asm.h in _setjmp.S.
Is there a way to force it to use i386/asm.h?
I had a go with gcc, but I got the same results...
There must be a certain setting on your system which causes this. Most
likely, it is again using your existing system headers, instead of those
in /usr/obj.
I suppose so, but where?
Thanks for your help, Edward
/etc/make.conf:
--
#
# Clang
#
USE_CLANG?=no
#
.if ${USE_CLANG} == "yes"
.if !defined(CC) || ${CC} == "cc"
CC=/usr/local/bin/clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=/usr/local/bin/clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
#CPP=/usr/local/bin/clang
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
NO_FSCHG=
.endif
#
# Build kernel options
#
BOOTWAIT=5
KERNCONF=AMD-Minimal
#
# Kernel modules
#
# Needed by ssh and bind
MODULES_OVERRIDE+=random
#
# Power management options
MODULES_OVERRIDE+=cpuctl cpufreq
#MODULES_OVERRIDE+=coretemp
#
# Legacy ATA support
MODULES_OVERRIDE+=ata/atacore ata/atapci
MODULES_OVERRIDE+=ata/atapicd
MODULES_OVERRIDE+=md
#
# File systems
MODULES_OVERRIDE+=procfs pseudofs
MODULES_OVERRIDE+=msdosfs cd9660
MODULES_OVERRIDE+=krpc nfscl nfscommon nfslock nfssvc
MODULES_OVERRIDE+=libiconv smbfs
#MODULES_OVERRIDE+=ntfs
#
# Networking
MODULES_OVERRIDE+=netgraph/netgraph
MODULES_OVERRIDE+=mii re
#
# USB
MODULES_OVERRIDE+=usb/usb
MODULES_OVERRIDE+=usb/ugensa
MODULES_OVERRIDE+=usb/uhci usb/ohci usb/ehci
# HIDs, keyboards and mice
MODULES_OVERRIDE+=usb/uhid usb/ukbd usb/ums
# Printers
#MODULES_OVERRIDE+=usb/ulpt
# Storage
MODULES_OVERRIDE+=usb/umass
#
# Graphic display
MODULES_OVERRIDE+=agp
MODULES_OVERRIDE+=drm/drm drm/i915
#
# Serial port
MODULES_OVERRIDE+=uart
#
# Parallel port
MODULES_OVERRIDE+=ppc ppbus lpt
# Parallel "Geek" port
#MODULES_OVERRIDE+=ppi
#
# I2C bus
#MODULES_OVERRIDE+=i2c/iicbus i2c/smbus i2c/smb
#MODULES_OVERRIDE+=i2c/controllers/intpm
#
# Sound
MODULES_OVERRIDE+=sound/sound sound/driver/hda
#
# Linux emulation
#MODULES_OVERRIDE+=linux linprocfs
#
# Needed for firefox HTML5
#MODULES_OVERRIDE+=sem
# added by use.perl 2012-02-16 20:40:59
PERL_VERSION=5.12.4
/etc/src.conf
--
# src.conf - Source build options
#WITHOUT_TOOLCHAINS="yes"
WITHOUT_ATM="yes"
WITHOUT_BLUETOOTH="yes"
WITHOUT_BSNMP="yes"
WITHOUT_CDDL="yes"
WITHOUT_CLANG="yes"
WITHOUT_CTM="yes"
WITHOUT_CVS="yes"
WITHOUT_GCC="yes"
#WITHOUT_GROFF="yes"
WITHOUT_IPX="yes"
WITHOUT_IPX_SUPPORT="yes"
WITHOUT_LIB32="yes"
WITHOUT_NCP="yes"
WITHOUT_OBJC="yes"
WITHOUT_PPP="yes"
WITHOUT_RCMDS="yes"
WITHOUT_RESCUE="yes"
WITHOUT_RCS="yes"
WITHOUT_SENDMAIL="yes"
WITHOUT_WIRELESS="yes"
WITHOUT_WIRELESS_SUPPORT="yes"
WITHOUT_WPA_SUPPLICANT_EAPOL="yes"
WITHOUT_ZFS="yes"
___
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: Clang as default compiler November 4th
On 12 Sep 2012, at 10:09, Doug Barton wrote: > Also, users who actually are helping with testing clang for ports > continue to report runtime problems, even with things that build fine. I hope that you are encouraging maintainers of ports that don't work as expected with clang to submit bug reports upstream. We can't fix bugs if we aren't made aware of them. David Current hat: LLVM / Clang developer.___ 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: Building world with clang ToT
On 2012-09-12 13:45, Edward Meewis wrote:
...
I added the following lines to each individual Makefile it stumbled on:
CFLAGS+= -I/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/include
LDADD+=-L/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/lib
or:
LDFLAGS+=-L/usr/obj/usr/home/emeewis/src/FreeBSD-HEAD/tmp/usr/lib
I hope to find a better place to set those, but it will do for now.
Normally this should never be done, but it could work in theory.
...
There must be a certain setting on your system which causes this. Most
likely, it is again using your existing system headers, instead of those
in /usr/obj.
I suppose so, but where?
...
/etc/make.conf:
--
#
# Clang
#
USE_CLANG?=no
#
.if ${USE_CLANG} == "yes"
.if !defined(CC) || ${CC} == "cc"
CC=/usr/local/bin/clang
Don't use absolute paths here, it will not work for buildworld. This
has been discussed recently in another thread. (Not an issue with
clang or gcc, but with the way buildworld bootstraps its compiler in
general.)
...
/etc/src.conf
--
# src.conf - Source build options
#WITHOUT_TOOLCHAINS="yes"
WITHOUT_ATM="yes"
WITHOUT_BLUETOOTH="yes"
WITHOUT_BSNMP="yes"
WITHOUT_CDDL="yes"
WITHOUT_CLANG="yes"
WITHOUT_CTM="yes"
WITHOUT_CVS="yes"
WITHOUT_GCC="yes"
I don't think buildworld can ever work correctly, if you have both
WITHOUT_CLANG and WITHOUT_GCC defined, at least not with how it is
currently implemented.
At least, certainly not for a -CURRENT build on -STABLE, that is. If
you'd build this on a fully installed -CURRENT box, it might complete,
but again, no guarantees.
Try building with gcc, while removing the WITHOUT_GCC line, or building
with clang, while removing the WITHOUT_CLANG line.
___
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: Clang as default compiler November 4th
On Wed, Sep 12, 2012 at 04:15:20AM -0500, Mark Linimon wrote: > On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote: > > At the moment the ports maintainers don't give much about if their ports > > build with CLANG or not because they're not forced to. > > I think this is a mis-representation. > > Adding the requirement "your ports must work on clang" is adding an > ex-post-facto requirement. This creates the following matrix of what > we are implicitly asking maintainers to do: > > (FreeBSD 7|8|9|10) * (amd64|arm|i386|powerpc|sparc64) * (base gcc|base clang) > > It is completely insane to expect anyone to be able to test in all of those > environments, or even a tiny subset of them. This isn't what most people > sign up for when they sign up to maintain ports. No, I didn't mean it that way. I only meant that the people / maintainers running CURRENT will actually see that their ports don't work and if they want to keep on using them on CURRENT they need to fix them. e.g. two of the ports I maintain don't build with CLANG, yet. I just checked that on the wiki page [1]. I had to look that up manually, but would have experienced that if I my CURRENT box was building with CLANG by default. :) It's clear that we cannot expect our maintainers to check all possible combinations of FreeBSD, architecture and compiler. > > > Those who don't run CURRENT won't notice, but those who do will have to > > get their butts up and fix the ports > > I think it's foolish to assume that maintainres don't have their butts in > gear as it is. Please note, we have nearly 1300 PRs, hundreds of ports with > build errors and/or PRs, and hundreds that fail on -current only. I try to > advertise all these things the best I know how. Adding the hundreds that > fail on -clang only and then blaming the maintainers is simply going to be > counter-productive. [1] http://wiki.freebsd.org/PortsAndClang pgpYzIi4erNuX.pgp Description: PGP signature
Re: Clang as default compiler November 4th
On Wed, Sep 12, 2012 at 03:03:43PM +0200, Lars Engels wrote: > two of the ports I maintain don't build with CLANG, yet. I > just checked that on the wiki page [1]. To repeat myself, the ports I've listed on that page are the "big problems". People need to look at the errorlogs URLs up at the top to see the complete list. mcl ___ 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: Clang as default compiler November 4th
Hello, Patrick. You wrote 12 сентября 2012 г., 1:22:44: PL> Well, I will not be able to run FreeBSD from scratch on my soekris :-) Thank you for warning, I've missed this. -- // Black Lion AKA Lev Serebryakov ___ 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: Building world with clang ToT
On 12-09-12 14:15, Dimitry Andric wrote: Try building with gcc, while removing the WITHOUT_GCC line, or building with clang, while removing the WITHOUT_CLANG line. I'll be damned, that did it! (with gcc) Thanks, guys! -- Ed. ___ 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"
recently updated -current fatal trap at boot
FreeBSD -current r240360 has a fatal trap at boot. This has been noted on two machines running -current which were updated using the recommended buildworld update procedure. Booting in single-user mode is possible and booting with the previous kernel, r240327M from ~ 09-10-12, is also possible and appears to run well. On the console the moment of failure is just after the config data for the last network device is displayed, where normally on the console is: add net default: gateway: 1.2.3.4 When pflog was enabled, pflog was the last item displayed, disabling pf and pflog has no effect. A serial console is not available so a picture of the console after the fatal trap is: https://picasaweb.google.com/lh/photo/vFCZkxwtD1iTis5FEFZPN3l5YW7gL02s7FRYfqxWRYs?feat=directlink Any recommendations toward finding the cause would be greatly appreciated. thanks -kim ___ 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: recently updated -current fatal trap at boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/12 11:48, Kim Culhan wrote: > FreeBSD -current r240360 has a fatal trap at boot. SVN r240367 reverts the troublesome change, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBQr+IACgkQQv9rrgRC1JKkSQCggIYLIw3nXzJgbsWhMID7vyKG rBoAoLPqm84XvhMhf8Ykp6bcwcedu8XJ =q3eX -END PGP SIGNATURE- ___ 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: recently updated -current fatal trap at boot
On Wed, Sep 12, 2012 at 11:48:45AM -0400, Kim Culhan wrote: > FreeBSD -current r240360 has a fatal trap at boot. > ... As noted yesterday, yes. You need to either revert r240344 or apply r240367 (which reverts r240344). FWIW, I had no trouble at r240388. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpf2wfs0uCe5.pgp Description: PGP signature
Re: Building world with clang ToT
On 2012-09-12 17:31, Edward Meewis wrote: On 12-09-12 14:15, Dimitry Andric wrote: Try building with gcc, while removing the WITHOUT_GCC line, or building with clang, while removing the WITHOUT_CLANG line. I'll be damned, that did it! (with gcc) Note that some people have been working on external toolchain support. This would aim to make it possible to do what you were trying, e.g. building world using WITHOUT_TOOLCHAIN, which sets both WITHOUT_CLANG and WITHOUT_GCC, among others. However, I am not sure how far these efforts have come by now. :-) ___ 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: Building world with clang ToT
On Wed, Sep 12, 2012 at 06:18:06PM +0200, Dimitry Andric wrote: > On 2012-09-12 17:31, Edward Meewis wrote: > > On 12-09-12 14:15, Dimitry Andric wrote: > >> Try building with gcc, while removing the WITHOUT_GCC line, or building > >> with clang, while removing the WITHOUT_CLANG line. > > > > I'll be damned, that did it! (with gcc) > > Note that some people have been working on external toolchain support. > > This would aim to make it possible to do what you were trying, e.g. > building world using WITHOUT_TOOLCHAIN, which sets both WITHOUT_CLANG > and WITHOUT_GCC, among others. > > However, I am not sure how far these efforts have come by now. :-) I've got some patches that aren't quite ready for prime-time that allow me to cross build world with an external CLANG. I'll post them to the toolchain@ list when they are closer to ready (hopefully quite soon). -- Brooks pgpnOOlvb5voa.pgp Description: PGP signature
Re: recently updated -current fatal trap at boot
On Wed, Sep 12, 2012 at 11:53 AM, Michael Butler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/12/12 11:48, Kim Culhan wrote: >> FreeBSD -current r240360 has a fatal trap at boot. > > SVN r240367 reverts the troublesome change, > > imb On Wed, Sep 12, 2012 at 11:57 AM, David Wolfskill wrote: > On Wed, Sep 12, 2012 at 11:48:45AM -0400, Kim Culhan wrote: >> FreeBSD -current r240360 has a fatal trap at boot. >> ... > > As noted yesterday, yes. You need to either revert r240344 or apply > r240367 (which reverts r240344). > > FWIW, I had no trouble at r240388. Thanks to both of you for pointing this out, rebuilding now. -kim ___ 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: Raspberry PI gets USB support [FreeBSD 10 current]
On Wednesday 12 September 2012 12:24:58 Alexander Yerenkow wrote: > We tested kernel built by gonzo@, there working framebuffer, ue0, and > USB2.0 devices (in theory, I didn't have those). > But after some activity (like download few megabytes file) all is stuck > with message > usb device stalled > > This is getting 100% repeatedly, no matter if download goes to sd card, or > to malloc-md-device. > If (When) this will be fixed, then Rpi would be a candy, prepared to > testing and more or less usable. > I have in plans try it with xorg-framebuffer, and with directfb, while > there's no video support. Hi, You should try a kernel after "r240419" Right now my code uses PIO mode and is a bit slow, but it should be more stable. Let's start from there and work on upwards? Anyone care to look into to optimising bus_space_region_4() calls to use load/store multiple? --HPS ___ 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: Clang as default compiler November 4th
On 9/12/2012 12:40 AM, Erik Cederstrand wrote: > Den 12/09/2012 kl. 11.29 skrev Doug Barton : > >> On 09/11/2012 02:52 AM, Erik Cederstrand wrote: >>> So can we do a sweep on the ports tree and mark the 2232 ports >>> with USE_GCC=4.2 until they can actually build with clang? >> >> Unfortunately it isn't that simple. We already have a >> statistically significant number of ports that don't even compile >> with gcc 4.2.1. How many compilers do we expect the users to >> install? :) > > If a port doesn't compile with the default compiler in base, I expect > that port to add a build dependency on the compiler that it actually > does compiles with. Yes, they do this now. The problem is that the set is growing, and the rate of growth is increasing. > Of course, I hope to not have 6 different > compilers installed on my system, but the list of build or runtime > dependencies are at the discretion of the port (maintainer). As you > (I think) said, we can't force port maintainers to patch their ports > to support clang. Those are unrelated issues. Please re-read the bits of my post that you snipped. The overwhelming majority of problems we have with compiling ports now would be fixed by having a modern version of gcc as the official (i.e., supported) "ports compiler." The clang efforts would be a parallel track. Doug ___ 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: Clang as default compiler November 4th
On 9/12/2012 1:49 AM, David Chisnall wrote: > On 12 Sep 2012, at 10:09, Doug Barton wrote: > >> Also, users who actually are helping with testing clang for ports >> continue to report runtime problems, even with things that build fine. > > I hope that you are encouraging maintainers of ports that don't work as > expected with clang to submit bug reports upstream. We can't fix bugs if we > aren't made aware of them. I personally am not directly involved in this effort (other than for my own ports), but from what I've seen the classical emphasis on pushing bug reports upstream has been applied in this area as well. hth, Doug ___ 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: Clang as default compiler November 4th
On 09/11/12 09:56, Dimitry Andric wrote: On 2012-09-11 16:27, Tijl Coosemans wrote:> On 11-09-2012 16:10, Dimitry Andric wrote: ... Yes, maths support, specifically precision, is admittedly still one of clang's (really llvm's) weaker points. It is currently not really a high priority item for upstream. This is obviously something that a certain part of our userbase will care a lot about, while most of the time they won't care so much about licensing or politics. So those people are probably better off using gcc for the time being. Does it affect the accuracy of libm functions? It seems to, at least in specific cases; Steve posted about this in an earlier thread on -current: http://docs.freebsd.org/cgi/mid.cgi?20120905221310.GA97847 ___ If true, this is a serious problem, especially for those of us who use FreeBSD in a scientific computing environment. -Nathan ___ 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: Clang as default compiler November 4th
On Tue, 11 Sep 2012, Erik Cederstrand wrote: > So can we do a sweep on the ports tree and mark the 2232 ports with > USE_GCC=4.2 until they can actually build with clang? This could allow > the clang switch to proceed. Hopefully, waiting for GCC to compile just > to install some tiny port will be enough of a nuisance for people to > eventually fix the remaining ports. To make it less painful, I just adjusted lang/gcc42 to not boostrap any more, rather just build. This allows for a full build in ten or less minutes on an old quad core I used for testing. Gerald ___ 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: Clang as default compiler November 4th
On Wed, Sep 12, 2012 at 04:42:27PM -0500, Nathan Whitehorn wrote: > On 09/11/12 09:56, Dimitry Andric wrote: > >On 2012-09-11 16:27, Tijl Coosemans wrote:> On 11-09-2012 16:10, > >Dimitry Andric wrote: > >... > >>>Yes, maths support, specifically precision, is admittedly still one of > >>>clang's (really llvm's) weaker points. It is currently not really a > >>>high priority item for upstream. > >>> > >>>This is obviously something that a certain part of our userbase will > >>>care a lot about, while most of the time they won't care so much about > >>>licensing or politics. So those people are probably better off using > >>>gcc for the time being. > >> > >>Does it affect the accuracy of libm functions? > > > >It seems to, at least in specific cases; Steve posted about this in an > >earlier thread on -current: > > > > http://docs.freebsd.org/cgi/mid.cgi?20120905221310.GA97847 > >___ > > If true, this is a serious problem, especially for those of us who use > FreeBSD in a scientific computing environment. Just to clarify. I do not oppose switching the default compiler to clang as long as the proponents for the switch have shown adequate testing. Neither clang successfully building world nor clang building a working kernel are adequate testing (IMHO). Neither of those "benchmarks" use floating point, and AFAIK the libm built by clang during a buildworld is not (extensively?) exercised. As far as the URL above, I've been fixing accuracy issues in the j0f() function, and so, I have a program that allows me to exhaustively test all possible input values in the range reported. For my locally patched j0f(), I saw the issue as reported in the URL, but in doing additional development on j0f() I accidentally deletely/lost that specific version of the code. I hope to regenerate the code from my notes this weekend, and redo the tests. In regards to my initial post in this thread, I was just trying to assess whether any benchmarks have been performed on FreeBSD for floating point generated by clang. Other than the limited testing that I've done, it appears that the answer is 'no'. -- 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"
Re: Clang as default compiler November 4th
Doug Barton writes:
> On 09/11/2012 02:52 AM, Erik Cederstrand wrote:
>> So can we do a sweep on the ports tree and mark the 2232 ports with
>> USE_GCC=4.2 until they can actually build with clang?
>
> Unfortunately it isn't that simple. We already have a statistically
> significant number of ports that don't even compile with gcc 4.2.1. How
> many compilers do we expect the users to install? :)
>
> What we need to do is what I and others have been asking to do for
> years. We need to designate a modern version of gcc (no less than 4.6)
> as the official default ports compiler, and rework whatever is needed to
> support this. Fortunately, that goal is much more easily achieved than
> fixing ports to build and run with clang. (It's harder than it sounds
> because there are certain key libs that define some paths depending on
> what compiler they were built with, but still easier than dealing with
> clang in the short term.)
To that effect ports also need to respect CC/CXX. There were a few -exp
runs without /usr/bin/{cc,gcc,etc} to find out non-conforming ones as
part of ports/159117. However, the issue was quickly shoved under the
carpet in order to focus on the more important, clang as default.
# last try, assumes_gcc are ports ignoring CC/CXX, many are fixed
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/index-reason.html
>
> Once that is done, the compiler in the base is an afterthought, and we
> can do away with gcc in the base altogether much more easily. Users who
> want to help support building ports with clang can continue to do so.
>
> Doug
--
Ignoring for the moment clang -exp runs are *still* done with clang 3.0
while we're discussing here clang 3.2 becoming default.
___
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: Clang as default compiler November 4th
On 2012-Sep-11, 23:29, Doug Barton wrote: > What we need to do is what I and others have been asking to do for > years. We need to designate a modern version of gcc (no less than 4.6) > as the official default ports compiler, and rework whatever is needed to > support this. Fortunately, that goal is much more easily achieved than > fixing ports to build and run with clang. (It's harder than it sounds > because there are certain key libs that define some paths depending on > what compiler they were built with, but still easier than dealing with > clang in the short term.) I like the idea very much. My only concern is that gcc is heavy to build. I can't imagine booting into a freshly installed production machine and having to install gcc just to build the couple of ports that I need there. Unless we provide a fast shortcut way to have make depends install gcc via pkg when needed, or some similar mechanism.. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpnuCIUIWf4L.pgp Description: PGP signature
Re: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 08:21:31AM +0200, Pietro Cerutti wrote: > On 2012-Sep-11, 23:29, Doug Barton wrote: > > What we need to do is what I and others have been asking to do for > > years. We need to designate a modern version of gcc (no less than 4.6) > > as the official default ports compiler, and rework whatever is needed to > > support this. Fortunately, that goal is much more easily achieved than > > fixing ports to build and run with clang. (It's harder than it sounds > > because there are certain key libs that define some paths depending on > > what compiler they were built with, but still easier than dealing with > > clang in the short term.) > > I like the idea very much. My only concern is that gcc is heavy to > build. Gerald has been advocating this for a while as well. In fact, he's just made a commit that makes the lang/gcc42 compiler much easier to bootstrap itself. There's a set of interlocking changes that we need to make to the infrastructure to modernize our compiler choices. I've been talking to Gerald about some of the aspects of it and hope to have something to propose fairly soon. But IMHO it's a little bit trickier than it appears at first glance. mcl ___ 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"
