On Thu, Jun 26, 2014 at 11:30:39AM -0700, Justin Hibbits wrote:
> On Thu, Jun 26, 2014 at 10:38 AM, Nathan Whitehorn
> <nwhiteh...@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).
>
> - Justinnathan, I all for what you did, except that we should also add arm to the clang list ;) 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
pgphzHQyBFjju.pgp
Description: PGP signature
