Date: Thu, 26 Jun 2014 12:03:42 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Baptiste Daroussin <bapt@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com> Cc: Alexey Dokuchaev <danfe@freebsd.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Boost 1.55.0 (Was: Re: PowerPC Packages) Message-ID: <53AC6E8E.7050700@freebsd.org> In-Reply-To: <20140626190050.GE24440@ivaldir.etoilebsd.net> References: <539DC0C5.60603@freebsd.org> <20140623131222.GA26450@FreeBSD.org> <20140625073340.GA57075@FreeBSD.org> <20140625072305.45baf39b@zhabar.att.net> <20140626100258.GA47002@FreeBSD.org> <53AC3DB2.3070902@freebsd.org> <20140626154416.GD24440@ivaldir.etoilebsd.net> <53AC5AA1.1030508@freebsd.org> <CAHSQbTDcZxj7Rc9Pu13E57apKLwqGqQq_ExA0vmQrtQa1uxThg@mail.gmail.com> <20140626190050.GE24440@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/26/14 12:00, Baptiste Daroussin wrote:
> On Thu, Jun 26, 2014 at 11:30:39AM -0700, Justin Hibbits wrote:
>> On Thu, Jun 26, 2014 at 10:38 AM, Nathan Whitehorn
>> <nwhitehorn@freebsd.org> wrote:
>>> On 06/26/14 08:44, Baptiste Daroussin wrote:
>>>> On Thu, Jun 26, 2014 at 08:35:14AM -0700, Nathan Whitehorn wrote:
>>>>> On 06/26/14 03:02, Alexey Dokuchaev wrote:
>>>>>> On Wed, Jun 25, 2014 at 07:23:05AM -0700, Justin Hibbits wrote:
>>>>>>> As I mentioned earlier, you can set "FAVORITE_COMPILER=gcc" in
>>>>>>> make.conf, and it'll build with gcc47.
>>>>>> FAVORITE_COMPILER looks more like a hack to me. Ideally boost's port
>>>>>> Makefile should be fixed instead.
>>>>>>
>>>>>> I also would rather use system compiler (whether it's gcc4.2 or clang)
>>>>>> instead of gcc47.
>>>>>>
>>>>>> ./danfe
>>>>>>
>>>>> Yes, it should be made to respect whatever cc is.
>>>> As long as cc is supported upstream, boost being a nightmare to maintain I
>>>> will
>>>> reject all patches that are not accepted upstream first, otherwise bumping
>>>> to
>>>> 1.56 will be painful.
>>>>
>>>> That said I fully support the effort.
>>>>
>>>> regards,
>>>> Bapt
>>>
>>> The following patch fixes the issue for me (as well as several other ports).
>>> I'll let you decide whether this is how you want to handle the problem.
>>> -Nathan
>>>
>>> Index: Mk/Uses/compiler.mk
>>> ===================================================================
>>> --- Mk/Uses/compiler.mk (revision 358026)
>>> +++ Mk/Uses/compiler.mk (working copy)
>>> @@ -75,7 +75,9 @@
>>> ALT_COMPILER_TYPE= none
>>> _ALTCCVERSION=
>>> .if ${COMPILER_TYPE} == gcc && exists(/usr/bin/clang)
>>> +.if ${ARCH} == amd64 || ${ARCH} == i386 # clang often non-default for a
>>> reason
>>> _ALTCCVERSION!= /usr/bin/clang --version
>>> +.endif
>>> .elif ${COMPILER_TYPE} == clang && exists(/usr/bin/gcc)
>>> _ALTCCVERSION!= /usr/bin/gcc --version
>>> .endif
>>> @@ -138,7 +140,7 @@
>>>
>>> .if ${_COMPILER_ARGS:Mc++11-lang}
>>> .if !${COMPILER_FEATURES:Mc++11}
>>> -.if defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} == gcc
>>> +.if (defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} == gcc) || (${ARCH}
>>> != amd64 || ${ARCH} != i386) # clang not always supported on Tier-2
>>> USE_GCC= yes
>>> CHOSEN_COMPILER_TYPE= gcc
>>> .elif (${COMPILER_TYPE} == clang && ${COMPILER_VERSION} < 33) ||
>>> ${COMPILER_TYPE} == gcc
>>>
>> bapt mentioned a while back about separating the concept of the 'base
>> compiler' and 'ports compiler'. Perhaps we need to explore this
>> again. It should be possible to mark ports as being dependencies for
>> the ports compiler, and all other ports would get built by said
>> compiler, while those are built by the base compiler. This way we can
>> take advantage of any enhancements we might get with a newer compiler
>> (like better altivec support and autovectorization from newer gcc,
>> better optimizations, etc).
>>
>> - Justin
> nathan, I all for what you did, except that we should also add arm to the clang
> list ;)
I think that should work automatically. Isn't clang cc on ARM? This only
has an affect if cc is gcc and clang is also installed. The assumption
is that clang is non-default for a reason in such cases (except for
stable/10 x86, which is special-cased).
-Nathan
> Can you look at compiler.mk and apply the same concept?
>
> justin I m still looking in that direction, but that implies the full c++ stack
> (which is a nightmare on all pre freebsd10) because anything asking for C++11
> support will require a newer libc++ than the one shipped in base in case we use
> gcc to build base. and mising libstdc++ all together can give you terrific
> headache sometime ;)
>
> regards,
> Bapt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53AC6E8E.7050700>