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: 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"
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
Re: FreeBSD 10.0-CURRENT: CLANG and port/clang weirdness!
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.
> 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.
-- Brooks
>
> Thanks for your response,
>
> regards
>
> Oliver
>
>
pgpHuFEOubJHM.pgp
Description: PGP signature
Re: FreeBSD 10.0-CURRENT: CLANG and port/clang weirdness!
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.
>
>
>> 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.
>
>
>> Since I can not simply change the search patch - I need to have
>> /usr/local/bin before /usr/bin, is there a way to avoid this confusion?
>
> Yes, don't install the clang port, or do install it, but manually move
> the conflicting executables away, or delete them. This can't be fixed
> without fixing the clang ports to accept an option to change the
> compiler names into something non-conflicting.
The LibreOffice package doesn't compile with the system's CLANG, so it
is installed whenever LibreOffice is installed.
We have on all workstations running FreeBSD LibreOffice installed and so
devel/llvm and lang/clang get installed, as far as I know.
>
>
> ...
>> My /etc/make.conf portion looks this:
>>
>>
>>
>> ##
>> ## CLANG
>> ##
>> .if !defined(NO_CLANG)
>> .if !defined(CC) || ${CC} == "cc"
>> CC= /usr/bin/clang
>> .endif
>> .if !defined(CXX) || ${CXX} == "c++"
>> CXX=/usr/bin/clang++
>> .endif
>> .if !defined(CPP) || ${CPP} == "cpp"
>> CPP=/usr/bin/clang-cpp
>> .endif
>
> As said, putting an absolute path in these settings will defeat the
> logic in buildworld. Please don't do it, until there is a system in
> place to make this possible. (This is actually one of the stated goals
> for 10.0, to be able to specify even external toolchains for building
> world.)
Changed back, so hopefully no danger to pollute the list with more
questions about failures ;-)
Since I'm using on most boxes 10.0, where can I read more about the new
toolchain approach?
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).
Thanks for your response,
regards
Oliver
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD 10.0-CURRENT: CLANG and port/clang weirdness!
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? :)
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.
Since I can not simply change the search patch - I need to have
/usr/local/bin before /usr/bin, is there a way to avoid this confusion?
Yes, don't install the clang port, or do install it, but manually move
the conflicting executables away, or delete them. This can't be fixed
without fixing the clang ports to accept an option to change the
compiler names into something non-conflicting.
...
My /etc/make.conf portion looks this:
##
## CLANG
##
.if !defined(NO_CLANG)
.if !defined(CC) || ${CC} == "cc"
CC= /usr/bin/clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=/usr/bin/clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=/usr/bin/clang-cpp
.endif
As said, putting an absolute path in these settings will defeat the
logic in buildworld. Please don't do it, until there is a system in
place to make this possible. (This is actually one of the stated goals
for 10.0, to be able to specify even external toolchains for building
world.)
___
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 10.0-CURRENT: CLANG and port/clang weirdness!
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.
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?
Since I can not simply change the search patch - I need to have
/usr/local/bin before /usr/bin, is there a way to avoid this confusion?
Building software with makefiles or self-created ports always refer to
the port's LLVM/CLANG, which is LLVM/CLANG 3.1 due to some reuqirements
of several ports.
I'm really confused. Am I missing some special knob here and fell into
this pit by not-having-the-knowledge? Or is it really this messy?
Well, I'd like to stay with the core's LLVM/CLANG, which is 3.2 whenever
I simply issue "clang" or "clang++" (a pity that LLVM isn't completely
installed).
My /etc/make.conf portion looks this:
##
## CLANG
##
.if !defined(NO_CLANG)
.if !defined(CC) || ${CC} == "cc"
CC= /usr/bin/clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=/usr/bin/clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=/usr/bin/clang-cpp
.endif
## Don't die on warnings
#NO_WERROR=
#WERROR=
## Don't forget this when using Jails!
#NO_FSCHG=
CFLAGS= -O3 -pipe # -fno-strict-aliasing
COPTFLAGS= -O3 -pipe
#
#CXXFLAGS+= -stdlib=libc++
.endif
My /etc/src.conf is attached.
If there is a clean way to distinguish, please help me.
Regards,
Oliver
#.if !defined(NO_CLANG)
#CC=/usr/bin/clang
#CXX= /usr/bin/clang++
#CPP= /usr/bin/clang-cpp
##
#CFLAGS+= -O3 -pipe # -fno-strict-aliasing
#COPTFLAGS+=-O3 -pipe
#CXXFLAGS+= -stdlib=libc++
#
## Don't die on warnings
#NO_WERROR=
#WERROR=
#
## Don't forget this when using Jails!
#NO_FSCHG=
# need clang++ to be built
#WITH_LIBCPLUSPLUS= YES
#
#WITH_CLANG_IS_CC= YES
#.endif
#
WITH_CLANG= YES
WITH_CLANG_EXTRAS= YES
#
WITH_LIBCPLUSPLUS= YES
#
WITH_BIND_LARGE_FILE= YES
WITH_BIND_SIGCHASE= YES
WITH_BIND_LIBS= YES
#
WITH_IDEA= YES
WITH_HESIOD=YES
#
#WITH_ICONV=YES
#WITH_BSD_GREP= YES
WITH_BSD_SORT= YES
#
WITH_BSDCONFIG= YES
#
#WITH_OFED= YES
#
MALLOC_PRODUCTION= YES
#
PORTS_MODULES= emulators/virtualbox-ose-kmod x11/nvidia-driver
signature.asc
Description: OpenPGP digital signature
