heads up: conversation about removing CVS from HEAD on arch@
Hi all, I started a thread about removing CVS from HEAD on arch. If you are interested in following or have something to say please use that list. -- Eitan Adler ___ 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"
Small Ivy features: FSGSBASE and SMEP.
Please find at http://people.freebsd.org/~kib/misc/smep.1.patch the patch which should enable the FSGSBASE and SMEP features supposedly present in the IvyBridge CPUs. FSGSBASE are four new instructions available in the 64bit mode only. They allow to access bases for %fs and %gs without touching MSRs. This makes it possible to both read and write bases in the user mode, or in ring 0 with lower overhead. At the moment, WRFSBASE/WRGSBASE instructions should work, but are useless since any interrupt or context switch overrides bases with the values set by the arch syscall. Still, RDFSBASE/RDGSBASE might be useful for some code and I see no reason not to enable them. SMEP is the nice feature of the processor which makes it trap if ring 0 tries to execute an instruction from usermode-accessible page. It is another mitigation for things like calling user-controllable function pointer in kernel, as well as a protection for NULL function pointer dereference. I am sure that we never execute anything in kernel from user page, but I did not tested the patch since I have no Ivy machine. I need your reports about boot on Ivy with patch applied. Please include the lines from verbose dmesg with CPU Features. In particular, the 'Standard Extended Features' report should appear in output. Thanks. pgpkeuFoG6WDV.pgp Description: PGP signature
Re: FreeBSD 10.0-CURRENT: CLANG and port/clang weirdness!
> The LibreOffice package doesn't compile with the system's CLANG, so it
> is installed whenever LibreOffice is installed.
FWIW, it's using base clang and it does compile if ${OSVERSION} >= 900014
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/FreeBSD-10-0-CURRENT-CLANG-and-port-clang-weirdness-tp5741455p5741777.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HELP: New Port: devel/pocl: A portable OpenCL library with LLVM backend
On Sat, Sep 08, 2012 at 10:57:49AM +0200, O. Hartmann wrote: > Hello. > I tried to create a "port", see the Makefile attached I created already. > For further informations and your convenience, look at this website: > Please stop cross posting to freebsd-current when you have some issue that clearly belongs in free-ports. -- 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"
10-CURRENT clock_getcpuclockid() usage
clock_getcpuclockid() was added a few weeks ago according to the man page and I'm seeing this error while building the port net/freeswith-core-devel. The function is used in the Sofia-sip stack, courtesy Nokia Research Center, incorporated into FreeSWITCH. The build system tests for the presence of clock_getcpuclockid() and finds it but in the error messages 'clock_getcpuclockid2' is mentioned. Any thoughts on the clock_getcpuclockid() usage would be very greatly appreciated. LTCOMPILE su_time.lo su_time.c:410:14: error: implicit declaration of function 'clock_getcpuclockid' is invalid in C99 [-Werror,-Wimplicit-function-declaration] else if (clock_getcpuclockid(0, &cpu) != -1 && ^ su_time.c:410:14: note: did you mean 'clock_getcpuclockid2'? else if (clock_getcpuclockid(0, &cpu) != -1 && ^~~ clock_getcpuclockid2 /usr/include/sys/time.h:352:5: note: 'clock_getcpuclockid2' declared here int clock_getcpuclockid2(id_t, int, clockid_t *); ^ 1 error generated. gmake[9]: *** [su_time.lo] Error 1 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: FreeBSD 10.0-CURRENT: CLANG and port/clang weirdness!
Am 08.09.2012 10:35, schrieb O. Hartmann:
> On 09/07/12 19:07, Brooks Davis wrote:
>> On Fri, Sep 07, 2012 at 05:46:02PM +0200, O. Hartmann wrote:
>>> On 09/07/12 17:09, Dimitry Andric wrote:
On 2012-09-07 11:41, O. Hartmann wrote:
> Building ports not explicitely enabling USE_GCC=4.6+ are
> considered using the system's LLVM/CLANG, which is clang
> 3.2 in our installation (FreeBSD 10.0-CURRENT #0 r240164),
> but since some ports require the special ports devel/llvm
> and lang/clang, LLVM 3.1 and clang 3.1 get installed and
> 3.1 is used instead the system's 3.2 whenever "clang",
> "clang++" is invoked.
Maybe a solution would be to use the same approach as with
the gcc ports, namely installing the clang 3.1 executables
into /usr/local/bin as clang-3.1, clang++-3.1 and
clang-cpp-3.1. Then you could simply set
CC=clang-3.1 CXX=clang++-3.1 CPP=clang-cpp-3.1
for the targets that require it. Brooks? :)
>>>
>>> I would appreciate such an approach, since it would be
>>> consistent with with GCC, as you stated.
>>
>> I'd like to do this, but it doesn't look like it will be easy.
>> There appears to be no support in the llvm build system for it.
>> :(
>>
> Following the WIKI at
> http://wiki.freebsd.org/BuildingFreeBSDWithClang introduces
> the usage of
>
> CC=clang instead of CC=/usr/bin/clang CXX=clang++ instead
> of CXX=/usr/bin/clang++ CPP=clang-ccp instead of
> CPP=/usr/bin/clang-ccp
>
> Is this intended?
Yes. During buildworld, in the cross-tools stage, a new
compiler is built, and it is placed under ${WORLDTMP},
usually /usr/obj/usr/src/tmp. Afterwards, in the rest of the
stages, the PATH is changed so executables from ${WORLDTMP}
are preferred above those in the system directories.
Therefore, if you set CC/CXX/CPP with an explicit path, this
logic will not work, and your buildworld may have all kinds
of trouble. I think there are several patches floating
around to fix this, in various different ways.
>>>
>>> Understood.
>>
>> FWIW, picking up clang etc from /usr/local should be mostly
>> harmless during the early build stage. You're actual world will
>> be built with the cross clang.
>
>
> ... means, the resulting WORLD and KERNEL is then build by the
> LLVM/CLANG that is residing in /usr/obj/...?
>
> But what is with PORTS I build later? They definitely pick up the
> "wrong" clang/clang++.
>
> I was suggested to deinstall (or not to install) the port's version
> of LLVM/CLANG, but this happens automatically for some ports -
> like LibreOffice.
Simple solution:
If /usr/local/bin must be in front of /usr/bin and the port version of
CLANG is thus found in preference of the system version, you may still
put another directory with symbolic links to system binaries in front
of /usr/local/bin. E.g.:
PATH=/usr/pref_bin:/usr/local/bin:/usr/bin
Directory /usr/pref_bin contains symbolic links to binaries in /usr/bin,
e.g. /usr/pref_bin/clang -> /usr/bin/clang.
Regards, STefan
___
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: FreeBSD 10.0-CURRENT: CLANG and port/clang weirdness!
On 2012-09-08 10:35, O. Hartmann wrote:
On 09/07/12 19:07, Brooks Davis wrote:
...
FWIW, picking up clang etc from /usr/local should be mostly harmless
during the early build stage. You're actual world will be built with
the cross clang.
... means, the resulting WORLD and KERNEL is then build by the
LLVM/CLANG that is residing in /usr/obj/...?
Yes. This is done so you can build an updated version of the system
compiler during the cross-tools stage, and then build the rest of the
world with this updated compiler.
But what is with PORTS I build later? They definitely pick up the
"wrong" clang/clang++.
If your search path has /usr/local/bin before /usr/bin, it will
obviously always pick up the ports-compiled clang, whatever version that
is.
If some other ports explicitly require clang 3.1, there should be a
mechanism to specifically invoke that version, instead of whatever the
first "clang" executable in the search path is.
For now, I think the best solution is to use the following (admittedly
rather kludgy) fragment in /etc/make.conf:
.if ${.CURDIR:M/usr/src*} || ${.CURDIR:M/usr/obj*}
CC=clang
CXX=clang++
CPP=clang-cpp
.else
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.endif
Or alternatively:
.if ${.CURDIR:M/usr/ports*}
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.else
CC=clang
CXX=clang++
CPP=clang-cpp
.endif
You're probably looking for WITH_CLANG_EXTRAS.
I already have that option enabled in my /etc/src.conf. But
unfortunately, a tool called "llvm-config" and sibblings weren't
installed, they get installed only with /usr/ports/devel/llvm[-devel].
This is on purpose, at least for now. The base system should only
contain the clang compiler proper, and none of the LLVM libraries. The
WITH_CLANG_EXTRAS option is just for getting a few tools that could be
handy, but should not be used by 99% of the users out there.
If you want the whole llvm and/or clang shebang, including the shared
libraries, just install the port. You can use the lang/clang-devel port
if you want to try out the bleeding edge version. AFAIK Brooks updates
it regularly.
___
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"
HELP: New Port: devel/pocl: A portable OpenCL library with LLVM backend
Hello.
I tried to create a "port", see the Makefile attached I created already.
For further informations and your convenience, look at this website:
POCL:
https://launchpad.net/pocl
LLVM:
http://llvm.org/docs/ReleaseNotes.html
I use FreeBSD 10.0-CURRENT r240186M amd64, my world and kernel are build
with CLANG.
The software, pocl, itself is straight forward able to compile. I didn't
"patch" anything or put magic sophisticated knowledge into "porting it",
I simply created the Makefile for the start. Feel free to work on it.
The Makefile is capable of building POCL on all FreeBSD 10 systems I
run, but it fails on FreeBSD 9.1-STABLE. I didn't investigate further,
since I have some first-priority questiosn and maybe some of the more
experienced people here are willing to contribute their knowledge.
0) In my CLANG built world, fetch(1) ends up with an "Authentication
error" fetching the sources from the site (see PR: bin/171402). This
needs to be fixed before the port works out of the box, you need to
download the source tar-ball manually for the first time from the site
mentioned above entitle POCL.
1) The port need to be build with a version number of the shared library
created - otherwise ldconfig doesn't seem to recognize the installed
library and does not load it into the cache.
2) A more sophisticated detection of the build environment is needed. I
failed providing a detection of the existence of a CLANG, legacy or GCC
> 4.6 build environment, I guess this can be done with the version
number of FreeBSD itself or with some knobs I do not know about. I'm new
to the ports system on this sophisticated level.
I think it is too early to announce this port with a PR, since FreeBSD <
10 isn't supported yet.
3) I didn't test the library with "real world" software, but I think I
will this in the near future, if it is working and usable. If some folks
could also provide "tests", please be invited.
Thanks.
Oliver
PORTNAME= pocl
PORTVERSION=0.6.0
CATEGORIES= devel
MAINTAINER= po...@freebsd.org
COMMENT=Portable OpenCL - an efficient open source
(MIT-licensed) implementation of the OpenCL 1.2 standard.
MASTER_SITES=
https://launchpad.net/pocl/${PORTVERSION:C/\.[0-9]$//}/${PORTVERSION}/+download/
DISTNAME= ${PORTNAME}-${PORTVERSION:C/\.[0-9]$//}
CONFLICTS= opencl-* freeocl*
DISABLE_MAKE_JOBS= yes
OPTIONS_SINGLE= LANG
OPTIONS_SINGLE_LANG=COMP_CLANG COMP_GCC
OPTIONS_DEFAULT=COMP_CLANG
COMP_CLANG_DESC=Use LLVM/CLANG compiler
COMP_GCC_DESC= Use GNU GCC compiler
.include
.if ${PORT_OPTIONS:MCOMP_GCC}
USE_GCC=4.6+
.endif
.if ${PORT_OPTIONS:MCOMP_CLANG}
CXXFLAGS+= -stdlib=libc++
CPPFLAGS+= -I${LOCALBASE}/include
.endif
BUILD_DEPENDS= ${LOCALBASE}/bin/llvm-config:${PORTSDIR}/devel/llvm
USE_GMAKE= yes
USE_GL= yes
USE_LDCONFIG= yes
USE_AUTOTOOLS= libltdl
GNU_CONFIGURE= yes
CPPFLAGS+= -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
.include
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD 10.0-CURRENT: CLANG and port/clang weirdness!
On 09/07/12 19:07, Brooks Davis wrote:
> On Fri, Sep 07, 2012 at 05:46:02PM +0200, O. Hartmann wrote:
>> On 09/07/12 17:09, Dimitry Andric wrote:
>>> On 2012-09-07 11:41, O. Hartmann wrote:
Building ports not explicitely enabling USE_GCC=4.6+ are considered
using the system's LLVM/CLANG, which is clang 3.2 in our installation
(FreeBSD 10.0-CURRENT #0 r240164), but since some ports require the
special ports devel/llvm and lang/clang, LLVM 3.1 and clang 3.1 get
installed and 3.1 is used instead the system's 3.2 whenever "clang",
"clang++" is invoked.
>>>
>>> Maybe a solution would be to use the same approach as with the gcc
>>> ports, namely installing the clang 3.1 executables into /usr/local/bin
>>> as clang-3.1, clang++-3.1 and clang-cpp-3.1. Then you could simply set
>>>
>>> CC=clang-3.1
>>> CXX=clang++-3.1
>>> CPP=clang-cpp-3.1
>>>
>>> for the targets that require it. Brooks? :)
>>
>> I would appreciate such an approach, since it would be consistent with
>> with GCC, as you stated.
>
> I'd like to do this, but it doesn't look like it will be easy. There
> appears to be no support in the llvm build system for it. :(
>
Following the WIKI at http://wiki.freebsd.org/BuildingFreeBSDWithClang
introduces the usage of
CC=clang instead of CC=/usr/bin/clang
CXX=clang++ instead of CXX=/usr/bin/clang++
CPP=clang-ccp instead of CPP=/usr/bin/clang-ccp
Is this intended?
>>>
>>> Yes. During buildworld, in the cross-tools stage, a new compiler is
>>> built, and it is placed under ${WORLDTMP}, usually /usr/obj/usr/src/tmp.
>>> Afterwards, in the rest of the stages, the PATH is changed so
>>> executables from ${WORLDTMP} are preferred above those in the system
>>> directories.
>>>
>>> Therefore, if you set CC/CXX/CPP with an explicit path, this logic will
>>> not work, and your buildworld may have all kinds of trouble. I think
>>> there are several patches floating around to fix this, in various
>>> different ways.
>>
>> Understood.
>
> FWIW, picking up clang etc from /usr/local should be mostly harmless
> during the early build stage. You're actual world will be built with
> the cross clang.
... means, the resulting WORLD and KERNEL is then build by the
LLVM/CLANG that is residing in /usr/obj/...?
But what is with PORTS I build later? They definitely pick up the
"wrong" clang/clang++.
I was suggested to deinstall (or not to install) the port's version of
LLVM/CLANG, but this happens automatically for some ports - like
LibreOffice.
>
>> Since I'm using on most boxes 10.0, where can I read more about the new
>> toolchain approach?
>
> Discussions will take place on the toolchain@ list. I'll be posting
> some writeups soon.
>
>> And by the way - is there a way to have also LLVM installed with the
>> base system by a knob like "WITH_LLVM"? This would avoid the same
>> confusion as mentioned above with CLANG when it comes to LLVM
>> dependencies (I play around with some OpenCL libs (pocl), which seems to
>> need LLVM port installed).
>
> You're probably looking for WITH_CLANG_EXTRAS.
I already have that option enabled in my /etc/src.conf. But
unfortunately, a tool called "llvm-config" and sibblings weren't
installed, they get installed only with /usr/ports/devel/llvm[-devel].
I discovered this playing around with LLVM and there is a software
package I play with (pocl, portable OpenCL library) which uses LLVM backend.
At this point, my "point of view" might me wrong, but I look at CLANG as
it is a part of the LLVM framework and so I inherently expected it to be
existent (the LLVM) in FreeBSD. But I guess the policy in FBSD is to
have only the clang and the necessary portions of LLVM in the tree. So I
thought it would be nice to have the "magic knob" in case one will take
the burden of compiling more and time consuming more LLVM/CLANG stuff if
he chooses to do.
>
> -- Brooks
>
>>
>> Thanks for your response,
>>
>> regards
>>
>> Oliver
>>
>>
>
signature.asc
Description: OpenPGP digital signature
