Bug 136607

Comment 1 Edwin Groothuis 2009-07-09 10:00:20 UTC

Responsible Changed
From-To: freebsd-ports-bugs->gerald

Over to maintainer (via the GNATS Auto Assign Tool)

Comment 2 Gerald Pfeifer 2009-07-12 21:41:30 UTC

State Changed
From-To: open->feedback

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?

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.

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

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.

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.

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.
>

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

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.

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

Comment 11 dfilter service 2009-12-01 11:37:08 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"

Comment 12 Gerald Pfeifer 2009-12-01 12:12:17 UTC

State Changed
From-To: feedback->closed

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).