From owner-freebsd-ports@FreeBSD.ORG Wed Sep 1 00:06:39 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9698A10656AC for ; Wed, 1 Sep 2010 00:06:39 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2BDEC8FC0C for ; Wed, 1 Sep 2010 00:06:39 +0000 (UTC) Received: by wyb33 with SMTP id 33so9958716wyb.13 for ; Tue, 31 Aug 2010 17:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=dxCFM5m6pe+ANaWXn0ecPf16M+tS1FC8JgTgpzljmRQ=; b=IWgPHBJ/lu4q6FqC326RExdKk8AY8bRQD9h6IsCG7QD28vMxjLxo+8xrCTOr29oefG 27psax32Oq2s8tjJlzdx8oxrjLnGqG0py/fPC9FHjkRzq5qX9Ka+q6xOKb0YSckEAOx+ 9+G8cLyVxwSCfNrujLW3Z+tWGyjoNDNrgbuGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=HUiHtkxbeuwOzUl9E/ke9mbw2BKbtmaaTgRhbYbIZaVvIziFhgumtuIUZFA3nuh8Oh BcDIYuir5+R+fLUQSaACviW3Bh8diLHv3TWqrcSNQU8kmHXJRrkHrFwBTjW5McfTObbp iHCeNyZBxW1UlkesX6uAKTrAScjY+kbcHzx7o= MIME-Version: 1.0 Received: by 10.227.37.212 with SMTP id y20mr6304788wbd.101.1283299589593; Tue, 31 Aug 2010 17:06:29 -0700 (PDT) Received: by 10.216.63.146 with HTTP; Tue, 31 Aug 2010 17:06:26 -0700 (PDT) In-Reply-To: <4C7D70CA.2070104@DataIX.net> References: <4C7D70CA.2070104@DataIX.net> Date: Wed, 1 Sep 2010 00:06:26 +0000 Message-ID: From: "b. f." To: jhell Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Ports Subject: Re: math/blas linking to gfortran with LDADD?= -lgfortran X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 00:06:39 -0000 On 8/31/10, jhell wrote: > On 08/31/2010 15:06, b. f. wrote: >> Would you elaborate, please? Where is a transcript showing the linking >> failure? >> Would you mail it to me off-list? > > Simply -lgfortran by it self should not work. Since lib directories > gcc44 gcc45 gcc46 and such are not in the standard path > -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for > it to be found. > > Off list should not be necessary. ? gfortran44 builds the object files, and gcc44 performs the linking for the shared library. Their default search directories normally allow them to find libgfortran at compile- and link-time. And afterwards, at run-time, the appropriate rpath is inscribed in the binary (see bsd.gcc.mk: this has been done for some time now), if the system linker hints aren't sufficient. So this does not seem to explain your problem, and that's why I asked for more complete information. Since I don't want to spam the list with that volume of material, that's why I asked for it to be sent via private email. > With my change in objdump the only thing listed in objdump -x that is > relevant to -lgfortran is the RPATH=/usr/local/lib/gcc44 and there is no > undefined symbols. As I said before, I cannot account for this -- I really need to see the complete information I requested earlier. Since gfortran44 is used to build the library components, there should be undefined symbols relating to libgfortran in all of the libraries, and the rpath should be present in both cases, if all you did was remove the explicit libgfortran from LDADD. The only difference should be the presence or absence of a DT_NEEDED tag for libgfortran. > Would it be possible with this to check for the existence of -lc_p > before and opt out automatically while warning the user that the > profiled libc was not found so profiling will be unavailable. ? I'll look into this. There is a dichotomy here: when building from source, base system profiling libraries are built and installed by default. The same may not be true if the user installs a binary distribution, using something like systinstall(8). It should be possible to handle both cases. On your subsequent question about the form of the statement: for math/lapack, yes, the statement could be changed to fit into the OPTIONS framework. But, as I wrote before, I put it in that form to mimic the similar statements in math/blas. The statements in math/blas must take into account the NO* variables, and WITHOUT_PROFILE, because the presence of these variables in the build environment or an included makefile is what actually controls whether the profiling libraries are built, via the relevant base system makefiles in /usr/share/mk, regardless of WITH_PROFILE. I will look into using the OPTIONS framework -- in the base system makefiles, unlike in Ports, there is a sanity check on the simultaneous use of WITH_FOO and WITHOUT_FOO. So there are some added safeguards, not normally available for Ports, that may make it possible to integrate this with OPTIONS. b.