From owner-freebsd-ports@FreeBSD.ORG Mon Sep 6 00:06:24 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 84F1810656A9 for ; Mon, 6 Sep 2010 00:06:24 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 364758FC18 for ; Mon, 6 Sep 2010 00:06:23 +0000 (UTC) Received: by gyg4 with SMTP id 4so1701923gyg.13 for ; Sun, 05 Sep 2010 17:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=yH8caRmMJZauz32APr98M4y2R3PYbcbtrS8+HOnreZ4=; b=npDKapup/ZY/2yGDq9XsrvyL39v6S/DiaCx8u+0rjWoUYDvu6Flzsp2mtRPC2RXR6C ZU+eoCWqtGw/HOD68Rc/O75vxDICe3XIz24E1GlhcgL+CeM/e/Ftg4Hw2Ml5Tr7ez1tp hg8ckmy2VsrHAIGvba2CH+3ob/wlta7cp5bzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=q6a7qqBrjeZDxkLoEhMlOpobewKsB6rzbXICTYJIPgt4/4Z8i3RXX1iECiMVmbv4Uj g3cnhDoJd61g6xJL2QhzgK6Rv4mtvOA/iueXZztm5IoFBfcynHSP3kDekyj9uHQ+geEQ Tfvk6GGbndoItbGNhQeFvb8lChM+u182bR55w= Received: by 10.150.144.15 with SMTP id r15mr1236792ybd.54.1283731583478; Sun, 05 Sep 2010 17:06:23 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id x3sm2838910ybl.22.2010.09.05.17.06.21 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Sep 2010 17:06:22 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C84307C.4070503@DataIX.net> Date: Sun, 05 Sep 2010 20:06:20 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Peter Jeremy References: <4C7D70CA.2070104@DataIX.net> <20100905191253.GA91710@server.vk2pj.dyndns.org> In-Reply-To: <20100905191253.GA91710@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bf1783@gmail.com, "b. f." , FreeBSD Ports Subject: [SOLVED]: math/blas linking to gfortran with LDADD?= -lgfortran X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 00:06:24 -0000 On 09/05/2010 15:12, Peter Jeremy wrote: > On 2010-Aug-31 17:14:50 -0400, 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 > > Actually, IMO, since libgfortran.so is a support library for gfortran > (much like libgcc_s.so is), it is reasonable for a user to expect > that '-lgfortran' _is_ sufficient and the current behaviour is a bug. > ports/129518 says I'm not the only person who think that. > >> -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for >> it to be found. > > And '-R/usr/local/lib/gcc44' as well. > > Note that a work-around has been added to bsd.gcc.mk so that ports > with USE_GCC shouldbehave correctly and the problem is limited to > using a non-base gcc outside the ports system. > Unfortunately this was caused by devel/ccache ;( or probably better said ccache attributed to finding this bug. The problem was that ccache was or is not liable for finding the lib/gccXX installs and therefore being called before, discards appropriate paths or whatnot ultimately borking the build. How I missed the problem was assuming that src.conf(5) is not used by ports(7) I had put the appropriate ccache, if then else statements in src.conf(5) to specifically keep it away from ports(7). As explained by b.f. math/blas being as old as it is uses files from /usr/src, so with that noted src.conf(5) gets pulled in and resulted in ccache being set by CC & CXX defines. The default if statement that I had in src.conf(5) was the one from the FreeBSD ccache example... Shouldn't have caught that right ??? think again... I had also set WRKDIRPREFIX=/usr/obj for ports(7)! in a if statement in make.conf(5) ARG!!! Here is the example: .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) Of course /usr/src is not empty here and of course /usr/obj is not empty, thats where I am compiling and of course I did not specify NOCCACHE because IMHO src.conf(5) should not be pulled into ports(7) at all. So needless to say I went the harder route of non-automation and changed that quickly to: .if defined(MY_LOCAL_DEFINE_HERE) && !defined(NOCCACHE) And now compiling graciously the ports I want with -DMY_LOCAL_DEFINE_HERE It would be real nice if someone could add NOCCACHE & WITHOUT_CCACHE to the ports .mk files so ports like math/blas can quickly override the use of ccache if the user decides to use the default example provided in local/share/doc/ccache/ccache-howto-freebsd.txt So to say the least there were multiple faulted layers here at play including me! Also math/lapack will not compile if a user has specified WITHOUT_PROFILE in there src.conf(5) specifically it wants libc_p.so.7 but a system with the above set will not have that installed. They are fixing this. Regards, -- jhell,v