From owner-freebsd-ports@freebsd.org Thu Aug 18 15:44:51 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 8CCE4BBE738; Thu, 18 Aug 2016 15:44:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7614F1EA3; Thu, 18 Aug 2016 15:44:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7IFio9D063009 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Aug 2016 08:44:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7IFioLh063008; Thu, 18 Aug 2016 08:44:50 -0700 (PDT) (envelope-from sgk) Date: Thu, 18 Aug 2016 08:44:50 -0700 From: Steve Kargl To: Dimitry Andric Cc: Tijl Coosemans , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160818154449.GA62868@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 18 Aug 2016 15:44:51 -0000 On Thu, Aug 18, 2016 at 02:48:28PM +0200, Dimitry Andric wrote: > On 18 Aug 2016, at 11:15, Tijl Coosemans wrote: > > > > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl wrote: > ... > >> % ldconfig -r | grep libgcc > >> 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > >> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 > >> > >> Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could > >> be convinced to build, install, and use libgcc_s6.so.1, then the > >> problem is solved without a wrapper. > > > > In this case the real cause of the problem is that compilers and linkers > > search /lib and /usr/lib last and ldconfig searches them first. Renaming > > the library is just a hack around that. > > Well, even if you would adjust the compilers and linkers to look in > /usr/local/lib first, how would you solve the problem of having > multiple, possibly incompatible versions of the same library in > different directories? > > For example, on one of my systems, I now have these: > > /usr/local/lib/gcc47/libgcc_s.so.1 > /usr/local/lib/gcc48/libgcc_s.so.1 > /usr/local/lib/gcc49/libgcc_s.so.1 > /usr/local/lib/gcc5/libgcc_s.so.1 > /usr/local/lib/gcc6/libgcc_s.so.1 > /usr/local/lib/gcc7/libgcc_s.so.1 > > So which one are you going to put at the front of the path? The gcc7 > version? If you are lucky that one is backwards compatible with all the > previous ones, but still I would like it much better if a program > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version > of libgcc_s.so. > > Steve's proposed scheme solves that quite nicely, in my opinion. The > problem is only in the details, as usual. There will be many configure > scripts and libtool-like utilities out there, that assume libgcc must be > linked using -lgcc_s, not -lgcc_s$VERSION. I asked on the gcc@gcc.gnu.org if there is a configure option to go the above, and unfortunately there isn't. I was pointed to --enable-version-specific-runtime-libs, but was then told that whatever it does is broken for multilib installs. I had not considered libtool-like utilities, so Dimitry is probably right in that this may open a can of worms. Another hack for the ports system would be to unilaterally include an -Wl,-rpath option on the gfortran commmand line. Currently, -Wl,-rpath is added to FFLAGS, FCFLAGS, and LDFLAGS in fortran.mk. The problem is that some ports might reset FFLAGS after fortran.mk has been included in Makefile. This should do the trick (watch for cut-n-paster whitespace corruption): Index: fortran.mk =================================================================== --- fortran.mk (revision 419226) +++ fortran.mk (working copy) @@ -26,9 +26,8 @@ RUN_DEPENDS+= gfortran${_GCC_VER}:lang/gcc${_GCC_VER} .endif USE_BINUTILS= yes -F77= gfortran${_GCC_VER} -FC= gfortran${_GCC_VER} -FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} +F77= gfortran${_GCC_VER} -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} +FC= gfortran${_GCC_VER} -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 One potential issues may be mixed-language apps that use Fortran libraries, but link with gcc or g++. -- Steve