--GUPx2O/K0ibUojHx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 26, 2014 at 12:03:42PM -0700, Nathan Whitehorn wrote:
>=20
> 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=3Dgcc" in
> >>>>>>> make.conf, and it'll build with gcc47.
> >>>>>> FAVORITE_COMPILER looks more like a hack to me. Ideally boost's p=
ort
> >>>>>> Makefile should be fixed instead.
> >>>>>>
> >>>>>> I also would rather use system compiler (whether it's gcc4.2 or cl=
ang)
> >>>>>> 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 main=
tain I
> >>>> will
> >>>> reject all patches that are not accepted upstream first, otherwise b=
umping
> >>>> 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 proble=
m.
> >>> -Nathan
> >>>
> >>> Index: Mk/Uses/compiler.mk
> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>> --- Mk/Uses/compiler.mk (revision 358026)
> >>> +++ Mk/Uses/compiler.mk (working copy)
> >>> @@ -75,7 +75,9 @@
> >>> ALT_COMPILER_TYPE=3D none
> >>> _ALTCCVERSION=3D
> >>> .if ${COMPILER_TYPE} =3D=3D gcc && exists(/usr/bin/clang)
> >>> +.if ${ARCH} =3D=3D amd64 || ${ARCH} =3D=3D i386 # clang often non-de=
fault for a
> >>> reason
> >>> _ALTCCVERSION!=3D /usr/bin/clang --version
> >>> +.endif
> >>> .elif ${COMPILER_TYPE} =3D=3D clang && exists(/usr/bin/gcc)
> >>> _ALTCCVERSION!=3D /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} =3D=3D gcc
> >>> +.if (defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} =3D=3D gcc) =
|| (${ARCH}
> >>> !=3D amd64 || ${ARCH} !=3D i386) # clang not always supported on Tier=
-2
> >>> USE_GCC=3D yes
> >>> CHOSEN_COMPILER_TYPE=3D gcc
> >>> .elif (${COMPILER_TYPE} =3D=3D clang && ${COMPILER_VERSION} < 33) ||
> >>> ${COMPILER_TYPE} =3D=3D 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 t=
he clang
> > list ;)
>=20
> I think that should work automatically. Isn't clang cc on ARM? This only=
=20
> has an affect if cc is gcc and clang is also installed. The assumption=20
> is that clang is non-default for a reason in such cases (except for=20
> stable/10 x86, which is special-cased).
> -Nathan
Ah true, please commmit that
regards,
Bapt
>=20
> > 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 cas=
e we use
> > gcc to build base. and mising libstdc++ all together can give you terri=
fic
> > headache sometime ;)
> >
> > regards,
> > Bapt
>=20
--GUPx2O/K0ibUojHx
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlOska0ACgkQ8kTtMUmk6EwI1wCeM0LTqp1n+602P4CXpYuhcLPO
v40AniDwbE2wpUreRgLxM9Umn5bcfhGG
=yIsI
-----END PGP SIGNATURE-----
--GUPx2O/K0ibUojHx--