head	1.2;
access;
symbols
	pkgsrc-2016Q4:1.1.0.22
	pkgsrc-2016Q4-base:1.1
	pkgsrc-2016Q3:1.1.0.20
	pkgsrc-2016Q3-base:1.1
	pkgsrc-2016Q2:1.1.0.18
	pkgsrc-2016Q2-base:1.1
	pkgsrc-2016Q1:1.1.0.16
	pkgsrc-2016Q1-base:1.1
	pkgsrc-2015Q4:1.1.0.14
	pkgsrc-2015Q4-base:1.1
	pkgsrc-2015Q3:1.1.0.12
	pkgsrc-2015Q3-base:1.1
	pkgsrc-2015Q2:1.1.0.10
	pkgsrc-2015Q2-base:1.1
	pkgsrc-2015Q1:1.1.0.8
	pkgsrc-2015Q1-base:1.1
	pkgsrc-2014Q4:1.1.0.6
	pkgsrc-2014Q4-base:1.1
	pkgsrc-2014Q3:1.1.0.4
	pkgsrc-2014Q3-base:1.1
	pkgsrc-2014Q2:1.1.0.2
	pkgsrc-2014Q2-base:1.1;
locks; strict;
comment	@# @;


1.2
date	2016.12.29.22.46.30;	author maya;	state dead;
branches;
next	1.1;
commitid	Ow92GGJ72no0PVzz;

1.1
date	2014.05.08.10.14.46;	author pho;	state Exp;
branches;
next	;
commitid	nMbkXh4eAECKIIzx;


desc
@@


1.2
log
@Remove gcc45,46,47 and libs as discussed in pkgsrc-users
GCC_REQD for these versions now resolves to gcc48 due to a previous commit.

Please file a bug report if you are having trouble with GCC 4.8.
@
text
@$NetBSD: patch-libgcc_config_t-slibgcc-darwin,v 1.1 2014/05/08 10:14:46 pho Exp $

If we don't install libgcc_s.10.[45].dylib, our gcc links binaries
with *both* /usr/lib/libgcc_s.1.dylib and
${GCC_PREFIX}/lib/libgcc_s.1.dylib, which is certainly a bad thing.

The problem was already reported to the upstream but it caught
seemingly no attention:
http://gcc.gnu.org/ml/gcc-help/2010-07/msg00164.html

--- libgcc/config/t-slibgcc-darwin.orig	2010-02-02 08:18:48.000000000 +0000
+++ libgcc/config/t-slibgcc-darwin
@@@@ -26,13 +26,7 @@@@ SHLIB_MKMAP = $(gcc_srcdir)/mkmap-flat.a
 SHLIB_MKMAP_OPTS = -v leading_underscore=1
 SHLIB_MAPFILES += $(gcc_srcdir)/libgcc-std.ver $(gcc_srcdir)/libgcc-libsystem.ver
 
-# we're only going to build the stubs if the target slib is /usr/lib
-# there is no other case in which they're useful in a live system.
-ifeq (/usr/lib,$(shlib_slibdir))
 LGCC_STUBS = libgcc_s.10.4.dylib libgcc_s.10.5.dylib
-else
-LGCC_STUBS =
-endif
 
 LGCC_FILES = libgcc_s.$(SHLIB_SOVERSION)$(SHLIB_EXT)
 LGCC_FILES += $(LGCC_STUBS)
@


1.1
log
@Darwin: Fix an issue that gcc producing binaries linked with a wrong libgcc_s

If we don't install libgcc_s.10.[45].dylib, our gcc links binaries
with *both* /usr/lib/libgcc_s.1.dylib and
${GCC_PREFIX}/lib/libgcc_s.1.dylib, which is certainly a bad thing.

The problem was already reported to the upstream but it caught
seemingly no attention:
http://gcc.gnu.org/ml/gcc-help/2010-07/msg00164.html
@
text
@d1 1
a1 1
$NetBSD$
@