From owner-freebsd-ports@freebsd.org Sun Aug 14 16:24:48 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4006BBB9B8E; Sun, 14 Aug 2016 16:24:48 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE691988; Sun, 14 Aug 2016 16:24:45 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id E8C212AA3A5; Sun, 14 Aug 2016 10:23:53 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 309171CDE4; Sun, 14 Aug 2016 12:24:36 -0400 (EDT) Date: Sun, 14 Aug 2016 12:24:36 -0400 From: Diane Bruce To: freebsd-toolchain@FreeBSD.org, freebsd-ports@freebsd.org Subject: Problems with our libgcc_s.so in base Message-ID: <20160814162436.GA32493@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 16:24:48 -0000 Problems with libgcc_s.so in base If you compile with gcc and use our base libgcc it should DTRT *provided* our libgcc has defined functions that are up to date with current libgcc We compile with gcc, it needs foo() from libgcc to run doesn't matter what foo() is (A typical function would be T __multi3) So our libgcc provides a foo() and gcc is happy This means in theory, we can interchangeably use gcc and clang in ports. This also means it made the initial port work from from gcc in base to clang in base a lot easier. The problems come when we try to use architectures not fully supported by our libgcc_s.so or when we use fortran. However, our libgcc lies in two ways 1) our libgcc is mostly not GPL code anymore, though there are bits and pieces of GPL depending on what we don't have. This includes (or did) some of the work ian@ was trying to do with arm, various bits that arm libgcc provides from gcc were missing. 2) It claims to be only up to date with GCC 4.2.4 Everything is peachy keen until someone references a symbol which is in anything gcc compiled using a newer > GCC 4.2.4 compiler. The moment you load libgfortran, it has a requirement for GCC_4.6 or better, and if our libgcc is already loaded things fail. The reason ports gcc now has this requirment on 4.6 or better is fortran standard says we have to support quad floating point math. e.g. /usr/local/lib/gccXX/libquadmath.so We *could* lie in our libgcc_s and claim to be 4.6 which would simply mean libgfortran would not complain and simply load the missing libquadmath. If we updated the claimed GCC version in our libgcc_s.so to claim GCC_4.6, we really also should provide a libquadmath subsitute. The other approach is to rename our libgcc_s.so to libclang_s.so or some such and link base with it instead of libgcc_s.so I frankly think this in the long term is the cleaner solution. In the ports world, we have papered over this problem by adding -Wl,-rpath=${_GCC_RUNTIME} or similar to force programs to link against /usr/local/lib/gcc${GCCVERSION}/libgcc_s.so However, any program that uses python to build has to be patched to force this stanza and our ports cmake presently does not force this stanza to be added. Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db