Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 May 2019 07:13:48 +0000 (UTC)
From:      Gerald Pfeifer <gerald@FreeBSD.org>
To:        ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org
Subject:   svn commit: r501002 - in head/lang/gcc8-devel: . files
Message-ID:  <201905080713.x487DmOE037655@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: gerald
Date: Wed May  8 07:13:48 2019
New Revision: 501002
URL: https://svnweb.freebsd.org/changeset/ports/501002

Log:
  Update to the 20180503 snapshot of GCC 8.3.1.
  
  On the way forward port r499061 | gerald | 2019-04-15 from lang/gcc8 [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/gcc8-devel/files/patch-gfortran-libgcc
     - copied unchanged from r500946, head/lang/gcc8/files/patch-gfortran-libgcc
Modified:
  head/lang/gcc8-devel/Makefile
  head/lang/gcc8-devel/distinfo

Modified: head/lang/gcc8-devel/Makefile
==============================================================================
--- head/lang/gcc8-devel/Makefile	Wed May  8 06:46:57 2019	(r501001)
+++ head/lang/gcc8-devel/Makefile	Wed May  8 07:13:48 2019	(r501002)
@@ -2,7 +2,7 @@
 # $FreeBSD$
 
 PORTNAME=	gcc
-PORTVERSION=	8.3.1.s20190426
+PORTVERSION=	8.3.1.s20190503
 CATEGORIES=	lang
 MASTER_SITES=	GCC/snapshots/${DIST_VERSION}
 PKGNAMESUFFIX=	${SUFFIX}-devel

Modified: head/lang/gcc8-devel/distinfo
==============================================================================
--- head/lang/gcc8-devel/distinfo	Wed May  8 06:46:57 2019	(r501001)
+++ head/lang/gcc8-devel/distinfo	Wed May  8 07:13:48 2019	(r501002)
@@ -1,3 +1,3 @@
-TIMESTAMP = 1556745588
-SHA256 (gcc-8-20190426.tar.xz) = 342295ab7baab1f7ad7110d1c3c00f29491d79c95aaed6c16f6e959024273fdf
-SIZE (gcc-8-20190426.tar.xz) = 61860168
+TIMESTAMP = 1557177682
+SHA256 (gcc-8-20190503.tar.xz) = d3e69578dd5295f0289d3eb1a8d6448c21671833adbd6f135da11feb9c310f63
+SIZE (gcc-8-20190503.tar.xz) = 61871888

Copied: head/lang/gcc8-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/gcc8-devel/files/patch-gfortran-libgcc	Wed May  8 07:13:48 2019	(r501002, 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201905080713.x487DmOE037655>