Re: amd64/181357: LCD Brightness Control not working on Lenovo X121e (ACPI issue?)
On 24/08/2013 17:08, Matthias Petermann wrote: regarding this PR I made some further observation. Even the acpi_ec_write seems to not have any effect on the brightness, the values set to the appropriate register (IBM_EC_BRIGHTNESS 0x31) survive a reboot. My LCD brightness control stopped working when I switched to NEW_XORG with Intel KMS (on stable/9). -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: MPSAFE VFS -- List of upcoming actions
On 19/09/2012 04:48, Attilio Rao wrote: On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org wrote: ... Alternatively, a kernel patch that should work with HEAD@240684 is here: http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch I guess the patch can easilly apply to all FreeBSD branches, really, but it is not tested to anything else different then -CURRENT. RELENG_9, fetched yesterday: === fuse (all) env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_device.c env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/fuse/../../fs/fuse/fuse_node.c distcc[20814] ERROR: compile /root/.ccache/tmp/fuse_node.tmp.mobileKamikaze.norad.20806.i on localhost failed cc1: warnings being treated as errors /usr/src/sys/modules/fuse/../../fs/fuse/fuse_node.c: In function 'fuse_vnode_setsize': /usr/src/sys/modules/fuse/../../fs/fuse/fuse_node.c:378: warning: passing argument 3 of 'vtruncbuf' makes pointer from integer without a cast /usr/src/sys/modules/fuse/../../fs/fuse/fuse_node.c:378: error: too few arguments to function 'vtruncbuf' *** [fuse_node.o] Error code 1 1 error *** [all] Error code 2 1 error *** [modules-all] Error code 2 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 Stop in /usr/src. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Compiler performance tests on FreeBSD 10.0-CURRENT
On 16/09/2012 00:34, Dimitry Andric wrote: ... The executive summary: GENERIC kernels compiled with clang 3.2 are slightly faster than those compiled by gcc 4.2.1, though the difference will not very noticeable in practice. It has been my impression in the past, that math heavy applications benefit from GCC whereas I/O heavy applications yield better performance when compiled with clang. I'd say a kernel has a lot more I/O than math to deal with. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Binary packages for LibreOffice 3.5 or 3.4
On 08/05/2012 08:53, Yamagi Burmeister wrote: I'd like to ask whether there are sites were binary packages could be downloaded from and are there any experiences with installing them on either 9-STABLE or 10-CURRENT? We (BSDForen.de) have unofficial packages build by the community at http://wiki.bsdforen.de/anwendungen/libreoffice_aus_inoffiziellen_paketen While the page is written in german, english (en_GB) packages are available. 7-STABLE, 8-STABE and 9-STABLE are covered. And the base version (without language packages) is always en_US. BTW, when our packages are a little late, this is normally for a reason. With the latest version it was the doc/docx issue. And of course there are a lot of packages to build. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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] Major snd_hda rewrite
Hello, On 11/01/2012 20:33, Alexander Motin wrote: I would like request for testing of my work on further HDA sound driver improvement. ... Comments and tests results are welcome! I've been testing the first version of your patch on an HP 6510b, since the 12th of January. hdac0@pci0:0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) HD Audio Controller' class = multimedia subclass = HDA mixer Mixer vol is currently set to 80:80 Mixer bass is currently set to 75:75 Mixer treble is currently set to 40:40 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 0:0 Mixer line is currently set to 0:0 Mixer mic is currently set to 0:0 Mixer rec is currently set to 50:50 Mixer igainis currently set to 0:0 Mixer ogainis currently set to 0:0 Mixer monitor is currently set to 0:0 Recording source: monitor So far I haven't encountered any regressions. There are however some small issues that also are present with the old driver. I have the following selection of recording devices: Mixer line is currently set to 0:0 Mixer mic is currently set to 0:0 Mixer monitor is currently set to 0:0 To record from the microphone, I have to use the monitor device: Recording source: monitor Physically neither the notebook nor the docking station have a line in socket. Of course such a thing might simply be on board and NC. Setting a volume for line, mic or monitor has no effect. To hear the microphone on my speakers/headphones I have to use igain instead. Igain sets the microphone volume independent of the recording source. There's also ogain, which doesn't seem to do anything either. What I expect is that the recording source for the microphone was mic and that the monitor recording source could be used to record the cumulative output of all channels. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: 9.0 RC1 linking problem with i386 libs on amd64
On 26/10/2011 16:39, Dimitry Andric wrote:
On 2011-10-26 15:32, Dominic Fandrey wrote:
I haven't tried to dig into this. Only unusual properties of the system
are my non-default MAKEOBJDIRPREFIX and the use of ccache.
# uname -a
FreeBSD AryaStark.norad 9.0-RC1 FreeBSD 9.0-RC1 #0: Wed Oct 26 13:46:13 CEST
2011 root@AryaStark.norad:/usr/obj/GENERIC/amd64/usr/src/sys/GENERIC
amd64
# make -VCC -VCPUTYPE -VCFLAGS
/usr/local/bin/ccache clang
athlon64-sse3
-O2 -pipe -march=athlon64-sse3
How are you setting CC and/or CFLAGS, precisely? Depending on how you
do it, the settings might not be propagated correctly to the build32
stage.
Like that:
.if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*}
CC=clang
CXX=clang++
CPP=clang-cpp
NO_WERROR=
WERROR=
.endif
I had hoped that the .ifdef construction from the wiki was dated. I
suppose it's emulating setting CC in the environment instead of in
the make/src.conf.
Also, if you force CFLAGS to have -march=athlon64-sse3, I'm not
sure if the build32 stage can even work correctly. Just specify
CPUTYPE, that should be enough.
That's what I do. I don't touch CFLAGS.
In any case, you can try out the attached patch, which should take care
of passing CC to the build32 stage correctly.
I tried CC?=, but that doesn't work, because apparently make always
initializes CC before parsing makefiles. I figure that means the
!defined(CC) clause in the .ifdef construction is never true and thus
obsolete.
I didn't try it, though. Your patch works for me.
I would really like to have this in head, and even stable/9. It makes
it possible to just set CC in make.conf, without .ifdef trickery. Works
nicely for clang, too. :)
Seconded!
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
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: 9.0 RC1 linking problem with i386 libs on amd64
On 28/10/2011 20:19, Dimitry Andric wrote:
On 2011-10-28 16:41, Dominic Fandrey wrote:
...
...
I had hoped that the .ifdef construction from the wiki was dated. I
suppose it's emulating setting CC in the environment instead of in
the make/src.conf.
There are two different problems here. One is that src.conf is read
relatively late, and only when bsd.own.mk is included. Therefore,
src.conf is not the right place to put CC, CXX and so on.
I use buildflags (sysutils/bsdadminscripts), hence all my build
configuration is included from the make.conf.
The other problem is that the build32 stage uses environment variables
to override CC, CXX, AS and LD for its sub-make (see LIB32WMAKEENV in
Makefile.inc1), adding the necessary flags for 32-bit compilation.
However, since environment variables are in turn overridden by direct
assignments (like via reading make.conf), the 32-bit compilation flags
get lost when you specify any of CC, CXX, AS or LD in make.conf.
This latter problem is what my patch attempts to fix, while changing as
little as possible.
An alternative is to pass __MAKE_CONF=/dev/null to the 32-bit stage.
That should also work in the environment, see make.conf(5)
DESCRIPTION§3.
I'm testing it now, just out of curiosity. One would probably have to
add a _WITHOUT_SRCCONF, to be src.conf compatible, too.
--- Makefile.inc1.orig 2011-10-28 22:00:20.0 +0200
+++ Makefile.inc1 2011-10-28 22:00:37.0 +0200
@@ -282,7 +282,8 @@
LIB32WMAKEENV= MACHINE=i386 MACHINE_ARCH=i386 \
MACHINE_CPU=i686 mmx sse sse2 \
LD=${LD} -m elf_i386_fbsd -Y P,${LIB32TMP}/usr/lib32 \
- AS=${AS} --32
+ AS=${AS} --32 \
+ __MAKE_CONF=/dev/null
.elif ${TARGET_ARCH} == powerpc64
.if empty(TARGET_CPUTYPE)
If there aren't any objections, I will commit it this weekend.
Thanks!
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
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
9.0 RC1 linking problem with i386 libs on amd64
I haven't tried to dig into this. Only unusual properties of the system are my non-default MAKEOBJDIRPREFIX and the use of ccache. # uname -a FreeBSD AryaStark.norad 9.0-RC1 FreeBSD 9.0-RC1 #0: Wed Oct 26 13:46:13 CEST 2011 root@AryaStark.norad:/usr/obj/GENERIC/amd64/usr/src/sys/GENERIC amd64 # make -VCC -VCPUTYPE -VCFLAGS /usr/local/bin/ccache clang athlon64-sse3 -O2 -pipe -march=athlon64-sse3 ... === lib/csu/i386-elf (obj,depend,all,install) ld -m elf_i386_fbsd -Y P,/usr/obj/GENERIC/amd64/usr/src/lib32/usr/lib32 -o gcrt1.o -r crt1_s.o gcrt1_c.o ld: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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
ClangBSD build failures
Hello, I wanted to make some performance comparisons, building ClangBSD with different compilers. The host system is: FreeBSD mobileKamikaze.norad 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Apr 5 12:45:41 CEST 2010 r...@mobilekamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 An interesting result is that buildkernel with clang takes longer: CC=clang time -l make buildkernel 921.31 real 802.25 user 114.93 sys time -l make buildkernel -j3 645.17 real 838.46 user 143.03 sys CC=cc time -l make buildkernel 877.14 real 757.42 user 115.11 sys time -l make buildkernel -j3 628.32 real 798.03 user 149.52 sys All the tests are run on a 4g memory disk (src and objdir), which is recreated for every test. I cannot make this comparison for buildworld, because buildworld with CC=cc, CXX=c++ fails: === usr.bin/clang/lib/libclanglex (all) c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1116: In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:34: In file included from
Re: ClangBSD build failures
On 27/04/2010 09:08, Roman Divacky wrote: On Tue, Apr 27, 2010 at 08:21:41AM +0200, Dominic Fandrey wrote: I cannot make this comparison for buildworld, because buildworld with CC=cc, CXX=c++ fails: === usr.bin/clang/lib/libclanglex (all) c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_C ONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_C ONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_C ONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1116: In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:34: In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:39: /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:63:18: error: use of undeclared identifier '__builtin_ia32_vec_init_v2si' return (__m64) __builtin_ia32_vec_init_v2si (__i, 0); you are using old clangbsd.. please update and this will go away Old as in less than 12 hours. :) I'll retry and report. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail
Re: ClangBSD build failures
On 27/04/2010 10:46, Roman Divacky wrote:
I see whats going on... you have CC=cc and CXX=c++ in your share/mk/sys.mk
and the c++ is clang thus the
Actually I set CC and CXX in the environment. The definition in
sys.mk is CC?=, so it shouldn't be a problem.
.if ${CC} == clang || ${CXX} == clang++
MMINTRIN_CLANG= -isystem ${WORLDTMP}/usr/include/clang/1.5
.endif
condition does not add the -isystem thus the gcc mmintrin.h is used.
you have to change the share/mk/sys.mk to have CC/CXX either gcc/g++
or clang/clang++
I have to think of some better way to test this as this proves way
too fragile :(
Thanks a lot for your quick analysis. I already changed my test script
to gcc and g++. Though I didn't think it would have an effect, I
figured sticking to the guide would generally be a good idea.
I didn't rerun the test, though. I have to wait for the night, when
the machine is not in use.
Anyway, thank you for figuring this out so quickly. It would seriously
have confused me that it would start working for no apparent reason
and I'd probably have blamed my hardware.
thnx for the report!
I'm working on a small clang introductory paper, and some
self-performed test seemed like the necessary salt, to give it the
right flavour. If you're interested I can notify you or the entire
list, when it's done.
Regards
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
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: ClangBSD build failures
On 27/04/2010 10:05, Roman Divacky wrote: On Tue, Apr 27, 2010 at 08:21:41AM +0200, Dominic Fandrey wrote: An interesting result is that buildkernel with clang takes longer: CC=clang time -l make buildkernel 921.31 real 802.25 user 114.93 sys time -l make buildkernel -j3 645.17 real 838.46 user 143.03 sys CC=cc time -l make buildkernel 877.14 real 757.42 user 115.11 sys time -l make buildkernel -j3 628.32 real 798.03 user 149.52 sys fwiw.. these are my times: clang: 403.342u 42.516s 6:53.30 107.8% 21957+2248k 33+56671io 364pf+0w gcc: 451.952u 42.860s 7:23.16 111.6% 6564+2012k 78+43200io 3pf+0w note that clang build had more page faults thus would be a little faster without them Nice compile times, and thank you for destroying my illusions that my Core2Duo notebook performs quite decently. :( The difference is alarmingly huge. I wonder whether the memory disk actually hurts performance. I will have to test this. I normally use ccache, and am used to a lot faster buildkernels and buildworlds, but I turned this off for the performance tests. So this didn't alarm me until I saw your measurements. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Trivial PR, fix shutdown of rc services started with onestart
On 12/04/2010 16:53, John Baldwin wrote: On Saturday 10 April 2010 5:33:35 am Dominic Fandrey wrote: This morning I took a look at my outstanding PRs. There is a PR I consider old and trivial: This one proposes a change that always treats rc script execution of active services as if service_enable=YES was set. This ensures, among other things, a clean shutdown procedure for services started with onestart: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/130414 You might want to send this to freebsd-rc@ if no one responds. Considering that they are the responsible party, do they not get notified by GNATS whenever I submit a follow-up to the PR? Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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
Trivial PR, fix shutdown of rc services started with onestart
This morning I took a look at my outstanding PRs. There is a PR I consider old and trivial: This one proposes a change that always treats rc script execution of active services as if service_enable=YES was set. This ensures, among other things, a clean shutdown procedure for services started with onestart: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/130414 Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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
