From mm@mail.vx.sk  Thu Jul  9 08:50:00 2009
Return-Path: <mm@mail.vx.sk>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B977E10656A3
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  9 Jul 2009 08:50:00 +0000 (UTC)
	(envelope-from mm@mail.vx.sk)
Received: from mail.vx.sk (core.vx.sk [188.40.32.143])
	by mx1.freebsd.org (Postfix) with ESMTP id 741878FC25
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  9 Jul 2009 08:50:00 +0000 (UTC)
	(envelope-from mm@mail.vx.sk)
Received: from localhost (localhost [127.0.0.1])
	by mail.vx.sk (Postfix) with ESMTP id BE1F82E4E1
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  9 Jul 2009 10:49:59 +0200 (CEST)
Received: from mail.vx.sk ([127.0.0.1])
	by localhost (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 1NZGMf-VvYE8 for <FreeBSD-gnats-submit@freebsd.org>;
	Thu,  9 Jul 2009 10:49:57 +0200 (CEST)
Received: by mail.vx.sk (Postfix, from userid 1001)
	id D92BD2E4DA; Thu,  9 Jul 2009 10:49:57 +0200 (CEST)
Message-Id: <20090709084957.D92BD2E4DA@mail.vx.sk>
Date: Thu,  9 Jul 2009 10:49:57 +0200 (CEST)
From: Martin Matuska <mm@freebsd.org>
Reply-To: Martin Matuska <mm@freebsd.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [PATCH] lang/gcc44: add OPTION for devel/binutils
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         136607
>Category:       ports
>Synopsis:       [PATCH] lang/gcc45: add OPTION for devel/binutils
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gerald
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jul 09 09:00:09 UTC 2009
>Closed-Date:    Tue Dec 01 14:13:13 UTC 2009
>Last-Modified:  Tue Dec 01 14:13:13 UTC 2009
>Originator:     Martin Matuska
>Release:        FreeBSD 7.2-STABLE amd64
>Organization:
>Environment:
System: FreeBSD 7.2-STABLE i386 and amd64
>Description:
When devel/binutils is installed, users of lang/gcc43 and lang/gcc44 may
use the full functionality of these compilers, e.g. CPU instructions
unsupported by system binutils like -mssse3 -msse4.1 -msse4.2

lang/gcc43 and lang/gcc44 automatically detect devel/binutils because it uses
standard paths.

I suggest setting this option to "on" by default in the future.
>How-To-Repeat:
>Fix:
Index: ports/lang/gcc43/Makefile
===================================================================
RCS file: /home/pcvs/ports/lang/gcc43/Makefile,v
retrieving revision 1.393
diff -u -r1.393 Makefile
--- ports/lang/gcc43/Makefile	22 Jun 2009 20:48:17 -0000	1.393
+++ ports/lang/gcc43/Makefile	9 Jul 2009 08:43:56 -0000
@@ -8,6 +8,7 @@
 
 PORTNAME=	gcc
 PORTVERSION=	4.3.4.20090621
+PORTREVISION=	1
 CATEGORIES=	lang java
 MASTER_SITES=	${MASTER_SITE_GCC}
 MASTER_SITE_SUBDIR=	snapshots/${VERSIONSTRING}
@@ -42,8 +43,15 @@
 PATCH_WRKSRC=	${SRCDIR}
 CONFIGURE_SCRIPT=	../${SRCDIR:S/${WRKDIR}\///}/configure
 
+OPTIONS=	BINUTILS	"Use binutils from ports"	off
+
 .include <bsd.port.pre.mk>
 
+.if defined(WITH_BINUTILS)
+BUILD_DEPENDS+=	${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
+RUN_DEPENDS+=	${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
+.endif
+
 .if ${ARCH} != i386
 WITHOUT_JAVA=	yes
 .endif
Index: ports/lang/gcc44/Makefile
===================================================================
RCS file: /home/pcvs/ports/lang/gcc44/Makefile,v
retrieving revision 1.390
diff -u -r1.390 Makefile
--- ports/lang/gcc44/Makefile	2 Jul 2009 01:02:21 -0000	1.390
+++ ports/lang/gcc44/Makefile	9 Jul 2009 08:43:56 -0000
@@ -8,6 +8,7 @@
 
 PORTNAME=	gcc
 PORTVERSION=	4.4.1.20090630
+PORTREVISION=	1
 CATEGORIES=	lang java
 MASTER_SITES=	${MASTER_SITE_GCC}
 MASTER_SITE_SUBDIR=	snapshots/${VERSIONSTRING}
@@ -42,8 +43,15 @@
 PATCH_WRKSRC=	${SRCDIR}
 CONFIGURE_SCRIPT=	../${SRCDIR:S/${WRKDIR}\///}/configure
 
+OPTIONS=	BINUTILS	"Use binutils from ports"	off
+
 .include <bsd.port.pre.mk>
 
+.if defined(WITH_BINUTILS)
+BUILD_DEPENDS+=	${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
+RUN_DEPENDS+=	${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
+.endif
+
 .if ${ARCH} != i386
 WITHOUT_JAVA=	yes
 .endif
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports-bugs->gerald 
Responsible-Changed-By: edwin 
Responsible-Changed-When: Thu Jul 9 09:00:20 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer (via the GNATS Auto Assign Tool) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=136607 
State-Changed-From-To: open->feedback 
State-Changed-By: gerald 
State-Changed-When: Sun Jul 12 20:41:30 UTC 2009 
State-Changed-Why:  
Hi Martin, 

thanks for the patch.  As you likely have seen recently my very clear 
preference (and the better solution for FreeBSD) would be to update 
the system copy of binutils.  Alas, I understand this is not likely 
going to happen soon, so let's consider your patch even though I am 
very concerned that it is going to caues difficulties down the path 
with harder to reproduce issues on users' systems. 

Practically, I would like to confine this to lang/gcc44 as the one 
stable version which is still somewhat active whereas lang/gcc43 is 
en route to being frozen (and I do plan to move USE_FORTRAN to then 
also use the former, so there should be no disadvantage).  Do you 
see any major concerns with this? 

Technically, I believe there is a problem with the patch in that it 
does enforce the binutils port to be installed, but it is not clear 
whether/when it is really going to be used _or_ if it is installed 
and the user disables the option, how we ensure it is not being used. 
The fact that the option does not affect the configuration/building 
of the port in any matter clearly indicates this will not work in 
all four combinations.  You may want to have a look at 
http://gcc.gnu.org/install/configure.html 
and see which configure options to best leverage and then run tests 
to ensure things really work properly in all four combinations. 

(--with-build-time-tools= might be what we need.) 

As a small final nit, we should look for a different name for the 
option since the system tools in FreeBSD come from binutils, too. 
PORTS_BINUTILS or similar perhaps? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=136607 

From: "b. f." <bf1783@googlemail.com>
To: gerald@freebsd.org, bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/136607: [PATCH] lang/gcc43 lang/gcc44: add OPTION for 
	devel/binutils
Date: Tue, 22 Sep 2009 15:53:55 +0000

 On 9/22/09, b. f. <bf1783@googlemail.com> wrote:
 > I've patched gcc45 along the lines I sketched in the recent exchange
 > on freebsd-ports@, and am starting a test build for the ports on my
 > machine.  I'll let you know the results tomorrow night.  I've renamed
 
 So far, so good.  Basically, in addition to instructing most of my
 ports to use gcc45, I've added to bsd.port.mk:
 
 
 --- Mk/old.bsd.port.mk  2009-09-22 09:54:45.000000000 -0400
 +++ Mk/new.bsd.port.mk  2009-09-22 10:04:00.000000000 -0400
 @@ -1739,6 +1739,33 @@
  CONFIGURE_ENV+=        MAKE=${GMAKE}
  .endif
 
 +.if defined(USE_BINUTILS_PORT)
 +BUILD_DEPENDS+=        ${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
 +RUN_DEPENDS+=  ${LOCALBASE}/bin/ld:${PORTSDIR}/devel/binutils
 +AR=    ${LOCALBASE}/bin/ar
 +AS=    ${LOCALBASE}/bin/as
 +LD=    ${LOCALBASE}/bin/ld
 +NM=    ${LOCALBASE}/bin/nm
 +OBJCOPY=       ${LOCALBASE}/bin/objcopy
 +OBJDUMP=       ${LOCALBASE}/bin/objdump
 +RANLIB=        ${LOCALBASE}/bin/ranlib
 +. if !defined{USE_LINUX) && !defined(WITH_DEBUG)
 +STRIP_CMD=     ${LOCALBASE}/bin/strip
 +. endif
 +CONFIGURE_ENV+=        AR=${AR} AS=${AS} NM=${NM} \
 +                               OBJDUMP=${OBJDUMP} OBJCOPY=${OBJCOPY} \
 +                               RANLIB=${RANLIB}
 +.endif
 +
 +.if defined(USE_GOLD) && ${OSVERSION} > 70041
 +BUILD_DEPENDS+=        ${LOCALBASE}/bin/ld-new:${PORTSDIR}/devel/gold
 +RUN_DEPENDS+=  ${LOCALBASE}/bin/ld-new:${PORTSDIR}/devel/gold
 +LD=    ${LOCALBASE}/bin/ld-new
 +.endif
 +.if defined (USE_BINUTILS_PORT) || defined(USE_GOLD)
 +CONFIGURE_ENV+=        LD=${LD}
 +.endif
 +
  .if defined(USE_GCC) || defined(USE_FORTRAN)
  .include "${PORTSDIR}/Mk/bsd.gcc.mk"
  .endif
 
 and to the lang/gcc45 port Makefile:
 
 --- old.Makefile        2009-09-18 17:34:10.000000000 -0400
 +++ new.Makefile        2009-09-22 11:30:19.000000000 -0400
 @@ -29,6 +29,7 @@
 
  VERSIONSTRING= ${PORTVERSION:C/([0-9]+\.[0-9]+).*\.([0-9]+)/\1-\2/}
  SUFFIX=                ${PORTVERSION:C/([0-9]+).([0-9]+).*/\1\2/}
 +SHLIBSUFFIX=   0${SUFFIX}
  LATEST_LINK=   gcc${SUFFIX}${PKGNAMESUFFIX}
  NOT_FOR_ARCHS= alpha ia64 powerpc
  USE_BISON=     build
 @@ -68,6 +69,16 @@
                 --libdir=${TARGLIB} \
                 --libexecdir=${LIBEXEC} \
                 --with-gxx-include-dir=${TARGLIB}/include/c++/
 +.ifdef(USE_BINUTILS_PORT)
 +CONFIGURE_ARGS+=       --with-build-time-tools=${LOCALBASE}/bin \
 +               --with-gnu-as=${AS} \
 +               --with-as=${AS}
 +.endif
 +.if defined(USE_BINUTILS_PORT) || defined(USE_GOLD)
 +CONFIGURE_ARGS+=       --with-gnu-ld=${LD} \
 +               --with-ld=${LD}
 +.endif
 +
  MAKE_ARGS+=    MAKEINFOFLAGS="--no-split"
  ALL_TARGET=    bootstrap-lean
  USE_LDCONFIG=  ${TARGLIB}
 @@ -91,9 +102,6 @@
  DISTFILES+=    gcc-java-${VERSIONSTRING}${EXTRACT_SUFX}
  BUILD_DEPENDS+=        zip:${PORTSDIR}/archivers/zip
  EXTRA_PATCHES+=        ${FILESDIR}/java-patch-hier
 -# FIXME: we are currently getting weird build failures with libjava on
 -# some 4.x and 5.x systems, which the following works around. PR 81788.
 -CONFIGURE_ARGS+=--disable-rpath
  MAN1+=         aot-compile${SUFFIX}.1 \
                 gappletviewer${SUFFIX}.1 \
                 gc-analyze${SUFFIX}.1 \
 @@ -158,6 +166,15 @@
  post-patch:
         @${REINPLACE_CMD} -e 's|\(const char version_string.*\)";|\1
 [FreeBSD]";|' \
             ${SRCDIR}/gcc/version.c
 +       @${REINPLACE_CMD} -e 's|SHLIB_SOVERSION = [0-9]\{1,\}|&${SHLIBSUFFIX}|'\
 +               ${SRCDIR}/gcc/config/t-slibgcc-elf-ver
 +       @${REINPLACE_CMD} -e
 's|\([0-9]\{1,\}\)\(:[0-9]\{1,\}:[0-9]\{1,\}\)|1\1${SHLIBSUFFIX}\2|'\
 +               ${SRCDIR}/libgfortran/libtool-version \
 +               ${SRCDIR}/libgomp/configure \
 +               ${SRCDIR}/libmudflap/libtool-version \
 +               ${SRCDIR}/libobjc/configure \
 +               ${SRCDIR}/libssp/libtool-version \
 +               ${SRCDIR}/libstdc++-v3/configure
 
  pre-configure:
         cd ${SRCDIR} ; contrib/gcc_update --touch
 
 
 The whitespace in these patches may not be preserved by gmail.
 
 The choice of new major versions for the shared libraries is somewhat
 arbitrary, although I had to keep leading digits nonzero, keep one or
 two digits that could be bumped if necessary, and fit them into an
 integer.  This choice gives, for the current libraries:
 
 /usr/local/lib/gcc45/libstdc++.so.16045
 /usr/local/lib/gcc45/libstdc++.so.16045-gdb.py
 /usr/local/lib/gcc45/libmudflap.so.10045
 /usr/local/lib/gcc45/libmudflapth.so.10045
 /usr/local/lib/gcc45/libssp.so.10045
 /usr/local/lib/gcc45/libgcc_s.so.1045
 /usr/local/lib/gcc45/libgfortran.so.13045
 /usr/local/lib/gcc45/libobjc.so.12045
 /usr/local/lib/gcc45/libgomp.so.11045
 
 The first and third digits can be bumped (the first is there primarily
 to eliminate leading zeros), the second corresponds to the original
 current major version number of the library, and the 45 indicate
 gcc45.
 
 I'm still sorting out the rpath directive -- it turns out (surprise,
 surprise!) that the configure scripts are overwriting rpath values in
 a convoluted way, and I have yet to unwind it.  This scheme so far has
 yielded a fair number of working ports on my system with
 USE_BINUTILS_PORT=yes.  I've yet to test USE_GOLD=yes and the old base
 binutils.  If we can sort out the rpath directive, I think this scheme
 is workable, will allow for people to take advantage of new compiler
 instruction sets, and will prevent most of the library conflicts we
 are now seeing.  The changes for gcc44 should be roughly equivalent.
 If the scheme is to be eventually used for most ports, rather than
 just those that USE_GCC or USE_FORTRAN, then some care must be taken
 to avoid circular dependencies, and ports using alternative build
 systems like Cmake and Qmake must be integrated.
 
 By the way, is there a reason why you didn't use math/mpc for gcc45?
 I know that you were originally planning to do so.  Is there a problem
 with mpc, or did you just run out of time?
 
 
 Regards,
                  b.

From: Gerald Pfeifer <gerald@pfeifer.com>
To: "b. f." <bf1783@googlemail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: ports/136607: [PATCH] lang/gcc43 lang/gcc44: add OPTION for 
 devel/binutils
Date: Thu, 24 Sep 2009 01:04:49 +0200 (CEST)

 On Tue, 22 Sep 2009, b. f. wrote:
 > +.if defined (USE_BINUTILS_PORT) || defined(USE_GOLD)
 
 Thanks for sharing your patch!  As a general note, I am seriously
 considering to make binutils a mandatory dependency for lang/gcc45.
 
 After a while (say a month or two) and a full pointyhat run, I would
 then imagine to backport this change to lang/gcc44.
 
 > +.if defined(USE_BINUTILS_PORT) || defined(USE_GOLD)
 
 At this point I am not (yet) looking at gold.  In my experience, the more 
 options we provide for such a key port like lang/gcc, the more troubles it 
 brings for many users and in the long term.  So, I strongly prefer to only 
 add options that have a very strong benefit for sufficiently many users.
 
 In the end, the more combinations there are, the less testing any 
 individual one will get, and then we'll see bug reports on specific
 version of FreeBSD with options A of port P and options B and C of
 port Q, but only on sparc64.
 
 So, if something like using newer binutils is generally positive, I'd
 rather bite the bullet and add the dependency.  I hope this makes sense?
 
 > The choice of new major versions for the shared libraries is somewhat
 > arbitrary, although I had to keep leading digits nonzero, keep one or
 > two digits that could be bumped if necessary, and fit them into an
 > integer.  This choice gives, for the current libraries:
 
 Your idea is cute.  I'd really try, and very hard so, to avoid deviating
 from the upstream .so names and versions.  In my experience, such stunts
 have always lead to problems over the years.  Now this depends on us
 finding another viable approach, which I've been trying to do and only
 with some success.
 
 > I'm still sorting out the rpath directive -- it turns out (surprise,
 > surprise!) that the configure scripts are overwriting rpath values in
 > a convoluted way, and I have yet to unwind it.
 
 Thanks for tackling this!
 
 > If the scheme is to be eventually used for most ports, rather than
 > just those that USE_GCC or USE_FORTRAN, then some care must be taken
 > to avoid circular dependencies, and ports using alternative build
 > systems like Cmake and Qmake must be integrated.
 
 This is an excellent point.  My priority #1 is to get those (few) with 
 USE_FORTRAN that are broken right now working again.  Priority #2 is to 
 then devise a cleaner patch and have a full round of testing for that, 
 which also addresses the USE_GCC cases.
 
 World domination is priority #3. :-=)
 
 > By the way, is there a reason why you didn't use math/mpc for gcc45?
 > I know that you were originally planning to do so.  Is there a problem
 > with mpc, or did you just run out of time?
 
 mpc is still moving somewhat fast and also the integration with GCC is
 not as complete yet.  My plan was and is to wait until GCC switches to
 the next stage in development which focuses on stabilization and then
 add math/mpc to the lang/gcc45 port.  Just a matter of timing, nothing
 else.
 
 Ah, and last but not least, below is my current plan of attack to solve
 priority #1 above.  Thoughts?
 
 Gerald
 
 Index: bsd.gcc.mk
 ===================================================================
 RCS file: /home/pcvs/ports/Mk/bsd.gcc.mk,v
 retrieving revision 1.33
 diff -u -3 -p -r1.33 bsd.gcc.mk
 --- bsd.gcc.mk	23 Sep 2009 21:13:07 -0000	1.33
 +++ bsd.gcc.mk	23 Sep 2009 22:17:24 -0000
 @@ -72,6 +72,8 @@ FC:=	gfortran44
  F77:=	gfortran44
  CC:=	gcc44
  CXX:=	g++44
 +CFLAGS+=	-Wl,-rpath=${PREFIX}/lib/gcc44
 +LDFLAGS+=	-Wl,-rpath=${PREFIX}/lib/gcc44
  
  # Intel Fortran compiler from lang/ifc.
  . elif ${USE_FORTRAN} == ifort

From: "b. f." <bf1783@googlemail.com>
To: Gerald Pfeifer <gerald@pfeifer.com>
Cc: bug-followup@freebsd.org
Subject: Re: ports/136607: [PATCH] lang/gcc43 lang/gcc44: add OPTION for 
	devel/binutils
Date: Thu, 24 Sep 2009 01:57:40 +0000

 On 9/23/09, Gerald Pfeifer <gerald@pfeifer.com> wrote:
 > On Tue, 22 Sep 2009, b. f. wrote:
 
 >
 > At this point I am not (yet) looking at gold.  In my experience, the more
 > options we provide for such a key port like lang/gcc, the more troubles it
 > brings for many users and in the long term.  So, I strongly prefer to only
 > add options that have a very strong benefit for sufficiently many users.
 
 gold is said to provide vast speedups for linking, which would
 certainly be of interest to many people.  But, one thing at a time.
 
 
 >
 > In the end, the more combinations there are, the less testing any
 > individual one will get, and then we'll see bug reports on specific
 > version of FreeBSD with options A of port P and options B and C of
 > port Q, but only on sparc64.
 >
 > So, if something like using newer binutils is generally positive, I'd
 > rather bite the bullet and add the dependency.  I hope this makes sense?
 
 
 Yes, of course.  My own personal preference is to allow for some
 choice, but, as you point out, this may increase the burden on
 maintainers
 
 >
 >> The choice of new major versions for the shared libraries is somewhat
 >> arbitrary, although I had to keep leading digits nonzero, keep one or
 >> two digits that could be bumped if necessary, and fit them into an
 >> integer.  This choice gives, for the current libraries:
 >
 > Your idea is cute.  I'd really try, and very hard so, to avoid deviating
 > from the upstream .so names and versions.  In my experience, such stunts
 > have always lead to problems over the years.  Now this depends on us
 > finding another viable approach, which I've been trying to do and only
 > with some success.
 >
 
 I can understand your reluctance to deviate from upstream, but this is
 most definitely _not_ a gratuitous change.
 
 I cannot emphasize too strongly that the presence of
 mutually-incompatible shared libraries with the same soname is the
 single greatest problem besetting the current USE_GCC/USE_FORTRAN
 arrangement in Ports, and the source of manyt of the problems that we
 are now seeing.
 
 Our current methods of linking make any such arrangement unworkable.
 It never should have occurred in the first place.  If you don't rename
 or reversion the libraries, or revert to static linking, then I cannot
 see how you are going to easily deal with the common situation of
 object A depending on both:
 
 --version 1 of shared object B, and also on
 --shared object C, which in turns depends on version 2 of shared
 object B, which is
 different from and incompatible with version 1 of object B, but has
 the same soname.
 
 This just won't work.  Symbol versioning, in it's current form, won't
 help: it will just provide a warning of problems (as it has done). No
 amount of rpath juggling is going to solve the problem: it will just
 ensure that at least one version of the library is loaded from a
 designated location first.  But either the second, incompatible
 version of the library won't be loaded at all, or it will be loaded,
 but at least some of it's symbols will be interposed upon by the
 incompatible instances of those symbols found in the version of the
 library that was loaded first.  Either of these outcomes will either
 lead to outright failures in linking, or, worse still, unexpected and
 difficult-to-diagnose run-time failures.  As far as I know, we don't
 have a counterpart of the dlmopen() found in Linux and Solaris, where
 each linked object can maintain a separate link-map list, insulated
 from the other lists in the same process, on which it can
 independently map most of it's own dependencies (and even if we did,
 there would still be problems to sort out).
 
 Reversioning the libraries seems to me to be the simplest way to
 address these problems.  The scheme I suggested, although somewhat
 arbitrary, is both consistent and workable.
 
 >
 > Gerald
 >
 > Index: bsd.gcc.mk
 > ===================================================================
 > RCS file: /home/pcvs/ports/Mk/bsd.gcc.mk,v
 > retrieving revision 1.33
 > diff -u -3 -p -r1.33 bsd.gcc.mk
 > --- bsd.gcc.mk	23 Sep 2009 21:13:07 -0000	1.33
 > +++ bsd.gcc.mk	23 Sep 2009 22:17:24 -0000
 > @@ -72,6 +72,8 @@ FC:=	gfortran44
 >  F77:=	gfortran44
 >  CC:=	gcc44
 >  CXX:=	g++44
 > +CFLAGS+=	-Wl,-rpath=${PREFIX}/lib/gcc44
 > +LDFLAGS+=	-Wl,-rpath=${PREFIX}/lib/gcc44
 >
 >  # Intel Fortran compiler from lang/ifc.
 >  . elif ${USE_FORTRAN} == ifort
 >
 Thoughts:
 
 First, and most importantly, a change of this sort, whether it is done
 in the configuration of the compiler, or in bsd.gcc.mk, is necessary
 but _not_ sufficient to solve the problems, as I have described above.
 
 Secondly, we still need to check to see that the compiler does not
 automatically prepend another (wrong) directory to the rpath, so the
 compiler rpath configuration probably still needs to be sorted out.
 The LDFLAGS addition needs to be issued whether or not the CFLAGS
 addition is made, for the benefit of those ports that invoke the
 loader directly.
 
 Thirdly, there has to be a cleanup to ensure that ports respect LDFLAGS.
 
 Of the 467 ports in my experiment, only about 30 failed to build with
 gcc45 and binutils 2.19.1.  A handful of these were due to gcc45 being
 more stringent than the system compiler about code constructs; one or
 two were due to regressions in gcc45; a few more failed because qmake4
 isn't set up to handle gcc45; and the remainder were due to the fact
 that the port didn't respect LD, AR, or LDFLAGS (ar from binutils
 2.19.1 doesn't recognize some flags that bsd ar does, like "z"; and
 the system ld often fails when trying to link code compiled with gcc45
 and binutils 2.19.1.  Some ports call ld directly instead of using LD,
 or call ld through a misuse of libtool.).  So there is some hope that
 you can accomplish this cleanup in a reasonable amount of time,
 especially for only those ports that USE_GCC or USE_FORTRAN.  If you
 need some help, let me know, and I will try to find some time to
 assist you.  Especially with World Domination.
 
 b.

From: "b. f." <bf1783@googlemail.com>
To: Gerald Pfeifer <gerald@pfeifer.com>
Cc: bug-followup@freebsd.org
Subject: Re: ports/136607: [PATCH] lang/gcc43 lang/gcc44: add OPTION for 
	devel/binutils
Date: Thu, 24 Sep 2009 09:27:08 +0000

 On 9/24/09, b. f. <bf1783@googlemail.com> wrote:
 > On 9/23/09, Gerald Pfeifer <gerald@pfeifer.com> wrote:
 
 > or call ld through a misuse of libtool.
 
 Something else to watch for: libtool is proving a bit of a problem
 when used with CC=gcc4*.  A number of ports pass arguments of the
 form:
 
 foo='$CC ...'
 
 or
 
 foo="\$CC ... "
 
 
 to libtool.  Because libtool is needed to build libgmp4, and thus
 gcc4*, it must itself be built without USE_GCC or USE_FORTRAN, to
 avoid circular dependencies.  This results in hardwired values for
 CC=cc or c++, LD=/usr/bin/ld, etc. in the configuration section of
 libtool.  Hence the port may be partly built with gcc4*, but then it
 attempts to link with libtool using cc, etc.  I"m not sure how you
 would prefer to handle this  -- patch the libtool port so that the
 libtool script only uses statements that can be overridden, like
 
 CC=${CC-cc}
 
 instead of hardwired values?  Or patch all of the ports that pass
 unexpanded arguments to libtool individually?  Or change
 bsd.autotools.mk to use a compiler(+toolchain)-specific libtool script
 for LIBTOOL?
 
 b.

From: "b. f." <bf1783@googlemail.com>
To: Gerald Pfeifer <gerald@pfeifer.com>
Cc: bug-followup@freebsd.org
Subject: Re: ports/136607: [PATCH] lang/gcc43 lang/gcc44: add OPTION for 
	devel/binutils
Date: Thu, 24 Sep 2009 09:35:52 +0000

 Obviously, I meant:
 
 CC=${CC:-cc}
 
 in my last message. Where is my coffee?...
 
 b.
 
 On 9/24/09, b. f. <bf1783@googlemail.com> wrote:
 > On 9/24/09, b. f. <bf1783@googlemail.com> wrote:
 >> On 9/23/09, Gerald Pfeifer <gerald@pfeifer.com> wrote:
 >
 >> or call ld through a misuse of libtool.
 >
 > Something else to watch for: libtool is proving a bit of a problem
 > when used with CC=gcc4*.  A number of ports pass arguments of the
 > form:
 >
 > foo='$CC ...'
 >
 > or
 >
 > foo="\$CC ... "
 >
 >
 > to libtool.  Because libtool is needed to build libgmp4, and thus
 > gcc4*, it must itself be built without USE_GCC or USE_FORTRAN, to
 > avoid circular dependencies.  This results in hardwired values for
 > CC=cc or c++, LD=/usr/bin/ld, etc. in the configuration section of
 > libtool.  Hence the port may be partly built with gcc4*, but then it
 > attempts to link with libtool using cc, etc.  I"m not sure how you
 > would prefer to handle this  -- patch the libtool port so that the
 > libtool script only uses statements that can be overridden, like
 >
 > CC=${CC-cc}
 >
 > instead of hardwired values?  Or patch all of the ports that pass
 > unexpanded arguments to libtool individually?  Or change
 > bsd.autotools.mk to use a compiler(+toolchain)-specific libtool script
 > for LIBTOOL?
 >
 > b.
 >

From: Gerald Pfeifer <gerald@pfeifer.com>
To: "b. f." <bf1783@googlemail.com>
Cc: bug-followup@freebsd.org
Subject: Re: ports/136607: [PATCH] lang/gcc43 lang/gcc44: add OPTION for 
 devel/binutils
Date: Sat, 26 Sep 2009 03:05:55 +0200 (CEST)

 On Thu, 24 Sep 2009, b. f. wrote:
 >> Your idea is cute.  I'd really try, and very hard so, to avoid deviating
 >> from the upstream .so names and versions.  In my experience, such stunts
 >> have always lead to problems over the years.
 > I can understand your reluctance to deviate from upstream, but this is
 > most definitely _not_ a gratuitous change.
 > 
 > I cannot emphasize too strongly that the presence of
 > mutually-incompatible shared libraries with the same soname is the
 > single greatest problem besetting the current USE_GCC/USE_FORTRAN
 > arrangement in Ports, and the source of manyt of the problems that we
 > are now seeing.
 
 There seems to be a big misunderstanding here: we are not taking
 about mutally incompatbile shared libraries with the same soname.
 
 GCC run-time libraries having the same name in later release (GCC 4.4 
 versus GCC 4.2 in form of the system compiler here) _are_ backwards 
 compatible.  And the GCC developers spend signficiant efforts to maintain 
 this.
 
 In other words, if we could replace /usr/lib/libstdc++.so.6 by the copy 
 created by lang/gcc44, that should work perfectly fine without any problem 
 at all.
 
 Sadly it's not as simple as
 
   mv /usr/local/lib/gcc44/libstdc++.so.6 /usr/lib/libstdc++.so.6
 
 but technically it would work!
 
 > --version 1 of shared object B, and also on
 > --shared object C, which in turns depends on version 2 of shared
 > object B, which is
 > different from and incompatible with version 1 of object B, but has
 > the same soname.
 
 Ex falso quodlibet. :-)  Later versions _are_ compatible with earlier
 ones.  Anything else would be a grave bug.
 
 For now I'm going to commit my suggested patch (which did fix the Octave 
 build) and will then update it to also apply for the USE_GCC case, which
 has been a dormant bug, not just USE_FORTRAN.
 
 > Thirdly, there has to be a cleanup to ensure that ports respect LDFLAGS.
 
 This is an excellent point.
 
 > Of the 467 ports in my experiment, only about 30 failed to build with
 > gcc45 and binutils 2.19.1.  A handful of these were due to gcc45 being
 > more stringent than the system compiler about code constructs; one or
 > two were due to regressions in gcc45
 
 Have you filed upstream bug reports for those that you consider 
 regressions?
 
 > So there is some hope that you can accomplish this cleanup in a 
 > reasonable amount of time, especially for only those ports that USE_GCC 
 > or USE_FORTRAN.  If you need some help, let me know, and I will try to 
 > find some time to assist you.  Especially with World Domination.
 
 Well, as for World Domination, ensuring ports properly use LDFLAGS 
 certainly sounds like a good effort.  That would be helpful.
 
 As for this PR we are currently discussing in :-), it's about lang/gcc4x
 using devel/binutils.  If you can submit a patch against lang/gcc45 that
 adds a dependency on binutils (and nothing else) that would be nice.  I
 hope this can be done without a need to patch ports/Mk?
 
 Gerald

Date: Sat, 26 Sep 2009 03:41:04 +0000
From: "b. f." <bf1783@googlemail.com>
Subject: Re: ports/136607: [PATCH] lang/gcc43 lang/gcc44: add OPTION for devel/binutils

 On 9/26/09, Gerald Pfeifer <gerald@pfeifer.com> wrote:
 > On Thu, 24 Sep 2009, b. f. wrote:
 
 > GCC run-time libraries having the same name in later release (GCC 4.4
 > versus GCC 4.2 in form of the system compiler here) _are_ backwards
 > compatible.  And the GCC developers spend signficiant efforts to maintain
 > this.
 >
 
 Yes, but I'm guessing that they didn't go to the trouble of providing
 different minor numbers and symbol versions just for show.  And there
 are also other factors, like the possibly different flags used to
 compile and link these libraries.
 
 > In other words, if we could replace /usr/lib/libstdc++.so.6 by the copy
 > created by lang/gcc44, that should work perfectly fine without any problem
 > at all.
 >
 > Sadly it's not as simple as
 >
 >   mv /usr/local/lib/gcc44/libstdc++.so.6 /usr/lib/libstdc++.so.6
 >
 > but technically it would work!
 
 What will happen if someone attempts to link a binary that first loads
 /usr/lib/libstdc++.so.6, through hardcoded rpath or otherwise, with a
 shared object from a port that was built with USE_GCC or USE_FORTRAN,
 and needs /usr/local/lib/gcc4*/libstdc++.so.6?
 
 >Later versions _are_ compatible with earlier ones. Anything else would be a grave bug.
 
 Reductio ad ridiculum. :)
 
 >
 > Have you filed upstream bug reports for those that you consider
 > regressions?
 >
 
 No, I was too lazy, or too busy, to bundle up the preprocessed code.
 I'll try to get around to it.  FYI(some of these have since been
 fixed):
 
 graphics/libGL, dri:
 71:main/texstore.c:2823:1: internal compiler error: in
 purge_dead_edges, at cfgrtl.c:2323
 
 x11-fonts/fontconfig:
 482:fcpat.c:1234:0: internal compiler error: verify_stmts failed
 
 graphics/djvulibre-nox11:
 1172:XMLTags.cpp:332:1: internal compiler error: verify_gimple failed
 
 various qt4 ports:
 devel/qmake4/work/qt-x11-opensource-src-4.4.3/qmake/generators/./makefile.cpp:312:1:
 internal compiler error: verify_gimple failed
 6:io/qfilesystemwatcher_kqueue.cpp:107:5: internal compiler error: in
 create_tmp_var, at gimplify.c:504
 303:io/qfilesystemwatcher_kqueue.cpp:107:5: internal compiler error:
 in create_tmp_var, at gimplify.c:504
 
 graphics/graphviz:
 encoder/slicetype.c:476:13: internal compiler error: verify_stmts failed
 
 
 >
 > As for this PR we are currently discussing in :-), it's about lang/gcc4x
 > using devel/binutils.  If you can submit a patch against lang/gcc45 that
 > adds a dependency on binutils (and nothing else) that would be nice.  I
 > hope this can be done without a need to patch ports/Mk?
 
 To wire gcc45 to use devel/binutils requires just a patch to that
 port.  But you must patch at least bsd.gcc.mk -- although I think the
 proper place for this is bsd.port.mk, because ports unrelated to
 USE_GCC and USE_FORTRAN may need to use devel/binutils -- and
 individual ports, to ensure that they are taught to use the proper
 AS, LD, AR, etc. This is because some of these ports invoke them
 directly, rather than through a call to the compiler.  Most of the
 ports that failed in my test did so because they attempted to use,
 directly or through devel/libtool22, another compiler or /usr/bin/ld
 to do linking, after having used gcc45 and binutils 2.19.1 for
 compilation, resulting in fatal errors.
 
 b.

From: Gerald Pfeifer <gerald@pfeifer.com>
To: bug-followup@freebsd.org, "b. f." <bf1783@googlemail.com>
Cc:  
Subject: Re: ports/136607: [PATCH] lang/gcc43 lang/gcc44: add OPTION for 
 devel/binutils
Date: Sun, 4 Oct 2009 20:56:20 +0200 (CEST)

 On Thu, 24 Sep 2009, b. f. wrote:
 > Because libtool is needed to build libgmp4, and thus
 > gcc4*, it must itself be built without USE_GCC or USE_FORTRAN, to
 > avoid circular dependencies.  This results in hardwired values for
 > CC=cc or c++, LD=/usr/bin/ld, etc. in the configuration section of
 > libtool.  Hence the port may be partly built with gcc4*, but then it
 > attempts to link with libtool using cc, etc.  I"m not sure how you
 > would prefer to handle this  -- patch the libtool port so that the
 > libtool script only uses statements that can be overridden, like
 > 
 > CC=${CC-cc}
 > 
 > instead of hardwired values?  Or patch all of the ports that pass
 > unexpanded arguments to libtool individually?  Or change
 > bsd.autotools.mk to use a compiler(+toolchain)-specific libtool script
 > for LIBTOOL?
 
 Good points!  I thought a bit about these, and think this is something
 to best raise with the libtool maintainer.  For the time being, not so
 many ports actually are built with USE_GCC/USE_FORTRAN, but I can see
 that someone (like you ;-) may want to try and build all ports using a
 more current version of GCC, and then this is important.
 
 (Note that this PR really is about the use of devel/binutils by lang/gcc*,
 where I am specifically open to use this for lang/gcc45.)
 
 Gerald

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/136607: commit references a PR
Date: Tue,  1 Dec 2009 11:37:08 +0000 (UTC)

 gerald      2009-12-01 11:36:59 UTC
 
   FreeBSD ports repository
 
   Modified files:
     lang/gcc45           Makefile 
   Log:
   Use current GNU binutils from ports (devel/binutils) instead of the
   system tools.  The latter are half a decade old and fail to properly
   support modern CPUs and their standard features such as SSE or AVX in
   the case of AMD64/Intel64 which means that they even break when using
   a simple -march=native.
   
   On the way, sort CONFIGURE_ARGS.
   
   PR:             140995, 136607
   
   Revision  Changes    Path
   1.416     +9 -5      ports/lang/gcc45/Makefile
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: feedback->closed 
State-Changed-By: gerald 
State-Changed-When: Tue Dec 1 12:12:17 UTC 2009 
State-Changed-Why:  
Not as an OPTION for now, but hardcoded, lang/gcc45 now depends on 
devel/binutils which fixes issues specifically supporting newer CPUs. 

Depending on user demand/feedback, we may move this to lang/gcc44, too, 
as an OPTION there (which requires explicitly passing configure options 
to the GCC build to make it deterministic (and allow disabling it for 
real). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=136607 
>Unformatted:
