From owner-freebsd-ports-bugs@FreeBSD.ORG Sun May 18 14:54:53 2014 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 824C25DB for ; Sun, 18 May 2014 14:54:53 +0000 (UTC) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7202068 for ; Sun, 18 May 2014 14:54:53 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 7C3DA2AA46B for ; Sun, 18 May 2014 08:54:51 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id B96501CC0B; Sun, 18 May 2014 09:54:50 -0500 (EST) Date: Sun, 18 May 2014 09:54:50 -0500 From: Diane Bruce To: freebsd-ports-bugs@FreeBSD.org Subject: Missing RPATH problem with gfortran related ports Message-ID: <20140518145450.GA12200@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 14:54:53 -0000 Uses/fortran.mk provides FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \ -L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin It turns out that cc on HEAD FreeBSD-10 passes the -Wl,-rpath information correctly to ld but the -B${LOCALBASE}/bin means ports ld is used which promptly ignores the -rpath option somehow. This means any port using both cc and gfortran that uses any C code will not properly insert the needed RPATH into the resultant binary. This will lead to errors about missing libgcc being the wrong version and the program will not run. This is the case I discovered with py-numpy in particular. The quick fix is to USE_GCC= yes in the Makefile. I hope that was coherent as I am still recovering from BSDCan ;) Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db