From owner-svn-ports-head@freebsd.org Wed May 15 10:02:39 2019 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68A84158BAEA; Wed, 15 May 2019 10:02:39 +0000 (UTC) (envelope-from gerald@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 071BF84C6C; Wed, 15 May 2019 10:02:39 +0000 (UTC) (envelope-from gerald@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D5921811A; Wed, 15 May 2019 10:02:38 +0000 (UTC) (envelope-from gerald@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x4FA2cNu004871; Wed, 15 May 2019 10:02:38 GMT (envelope-from gerald@FreeBSD.org) Received: (from gerald@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x4FA2cYR004867; Wed, 15 May 2019 10:02:38 GMT (envelope-from gerald@FreeBSD.org) Message-Id: <201905151002.x4FA2cYR004867@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gerald set sender to gerald@FreeBSD.org using -f From: Gerald Pfeifer Date: Wed, 15 May 2019 10:02:38 +0000 (UTC) To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r501705 - in head/lang/gcc10-devel: . files X-SVN-Group: ports-head X-SVN-Commit-Author: gerald X-SVN-Commit-Paths: in head/lang/gcc10-devel: . files X-SVN-Commit-Revision: 501705 X-SVN-Commit-Repository: ports MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 071BF84C6C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.97)[-0.971,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 10:02:39 -0000 Author: gerald Date: Wed May 15 10:02:37 2019 New Revision: 501705 URL: https://svnweb.freebsd.org/changeset/ports/501705 Log: Update to the 20190512 snapshot of GCC 10.0.0. This brings a new binary bin/lto-dump which may be helpful if you employ link-time optimization (LTO). Forward port r499061 | gerald | 2019-04-15 from lang/gcc8 and gcc8-devel [1]: GCC has two runtime libraries: The static library libgcc.a (-lgcc) and the shared library libgcc_s.so (-lgcc_s). Both implement many of the same functions but they also each have their unique functions. When GCC links programs and libraries there are three possibilities: 1. gcc -static-libgcc or gcc -static: -lgcc => Just use libgcc.a. 2. gcc -shared-libgcc: -lgcc_s -lgcc => Link with libgcc_s first, so libgcc.a is only used for its unique functions. 3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed => Link with libgcc.a first so libgcc_s is only used for its unique functions (_Unwind_* functions). Approach 3 is the default for gcc and it's also what clang and clang++ use; approach 2 is the default for gfortran, g++ and probably other front ends. This patch makes 3 the default for gfortran. It significantly reduces the use of libgcc_s. The _Unwind_* functions are also available in the old base system libgcc_s which means this reduces the need for -rpath /usr/local/lib/gccN in ports that depend on libraries built with gfortran. Consider a dependency tree like this: prog -> libA -> libgcc_s (old base system libgcc_s is fine) -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s) Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's a normal C program compiled with clang. Without -rpath it will fail to start because it loads old libgcc_s first as a dependency of libA and then it fails to load libB. With this patch libB works with old base system libgcc_s or may not need libgcc_s at all, so prog does not need to be linked with -rpath. PR: 208120 [1] Submitted by: tijl [1] Added: head/lang/gcc10-devel/files/patch-gfortran-libgcc - copied unchanged from r500946, head/lang/gcc8/files/patch-gfortran-libgcc Modified: head/lang/gcc10-devel/Makefile head/lang/gcc10-devel/distinfo head/lang/gcc10-devel/pkg-plist Modified: head/lang/gcc10-devel/Makefile ============================================================================== --- head/lang/gcc10-devel/Makefile Wed May 15 09:56:42 2019 (r501704) +++ head/lang/gcc10-devel/Makefile Wed May 15 10:02:37 2019 (r501705) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= gcc -PORTVERSION= 10.0.0.s20190505 +PORTVERSION= 10.0.0.s20190512 CATEGORIES= lang MASTER_SITES= GCC/snapshots/${DIST_VERSION} PKGNAMESUFFIX= ${SUFFIX}-devel Modified: head/lang/gcc10-devel/distinfo ============================================================================== --- head/lang/gcc10-devel/distinfo Wed May 15 09:56:42 2019 (r501704) +++ head/lang/gcc10-devel/distinfo Wed May 15 10:02:37 2019 (r501705) @@ -1,3 +1,3 @@ -TIMESTAMP = 1557174273 -SHA256 (gcc-10-20190505.tar.xz) = 5ef4500a9e440fd9469dabd0a7d2ece133932c199573a70eae38af09b0940a3e -SIZE (gcc-10-20190505.tar.xz) = 68789736 +TIMESTAMP = 1557768236 +SHA256 (gcc-10-20190512.tar.xz) = c24dd4e26a4e3c0cc57a32041afbe592faea6a7145d8cf0124a5bfba65d1798b +SIZE (gcc-10-20190512.tar.xz) = 68819180 Copied: head/lang/gcc10-devel/files/patch-gfortran-libgcc (from r500946, head/lang/gcc8/files/patch-gfortran-libgcc) ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/lang/gcc10-devel/files/patch-gfortran-libgcc Wed May 15 10:02:37 2019 (r501705, copy of r500946, head/lang/gcc8/files/patch-gfortran-libgcc) @@ -0,0 +1,70 @@ +GCC has two runtime libraries: The static library libgcc.a (-lgcc) and +the shared library libgcc_s.so (-lgcc_s). Both implement many of the +same functions but they also each have their unique functions. When +gcc links programs and libraries there are three possibilities: + +1. gcc -static-libgcc or gcc -static: -lgcc + => Just use libgcc.a. + +2. gcc -shared-libgcc: -lgcc_s -lgcc + => Link with libgcc_s first, so libgcc.a is only used for its unique + functions. + +3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed + => Link with libgcc.a first so libgcc_s is only used for its unique + functions (_Unwind_* functions). + +Approach 3 is the default for gcc and it's also what clang and clang++ use; +approach 2 is the default for gfortran, g++ and probably other front ends. + +This patch makes 3 the default for gfortran. It significantly reduces +the use of libgcc_s. The _Unwind_* functions are also available in the +old base system libgcc_s which means this reduces the need for +-rpath /usr/local/lib/gccN in ports that depend on libraries built with +gfortran. Consider a dependency tree like this: + + prog -> libA -> libgcc_s (old base system libgcc_s is fine) + -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s) + +Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's +a normal C program compiled with clang. Without -rpath it will fail to +start because it loads old libgcc_s first as a dependency of libA and then +it fails to load libB. With this patch libB works with old base system +libgcc_s or may not need libgcc_s at all, so prog does not need to be +linked with -rpath. + +Upstream is unlikely accept a patch like this because libgfortran calls +some _Unwind_* functions and so always needs libgcc_s. Also because +every Fortran program and library links to libgfortran it makes sense +that option 2 above is the default. On FreeBSD where clang and GCC +compiled code can be mixed and where multiple libgcc_s may be installed, +option 3 is just a lot easier to deal with. + +The bug that sparked this is PR 208120 (but note there's a lot of +misleading information in that bug. CMake is not actually doing +anything wrong.) + +--- UTC +--- gcc/fortran/gfortranspec.c.orig 2015-06-26 17:47:23 UTC ++++ gcc/fortran/gfortranspec.c +@@ -404,7 +404,7 @@ For more information about these matters + } + } + +-#ifdef ENABLE_SHARED_LIBGCC ++#if 0 + if (library) + { + unsigned int i; + +--- libgfortran/Makefile.in.orig 2019-02-22 14:22:13.000000000 +0000 ++++ libgfortran/Makefile.in 2019-02-27 16:27:08.856408000 +0000 +@@ -625,7 +625,7 @@ + $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \ + $(HWCAP_LDFLAGS) \ + -lm $(extra_ldflags_libgfortran) \ +- $(version_arg) -Wc,-shared-libgcc ++ $(version_arg) + + libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP) + cafexeclib_LTLIBRARIES = libcaf_single.la Modified: head/lang/gcc10-devel/pkg-plist ============================================================================== --- head/lang/gcc10-devel/pkg-plist Wed May 15 09:56:42 2019 (r501704) +++ head/lang/gcc10-devel/pkg-plist Wed May 15 10:02:37 2019 (r501705) @@ -17,6 +17,7 @@ bin/gcov%%SUFFIX%% bin/gcov-dump%%SUFFIX%% bin/gcov-tool%%SUFFIX%% bin/gfortran%%SUFFIX%% +bin/lto-dump%%SUFFIX%% man/man1/cpp%%SUFFIX%%.1.gz man/man1/g++%%SUFFIX%%.1.gz man/man1/gcc%%SUFFIX%%.1.gz