From owner-freebsd-ports@FreeBSD.ORG Wed Sep 1 03:46:35 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 6D9DB1065694 for ; Wed, 1 Sep 2010 03:46:35 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1263B8FC08 for ; Wed, 1 Sep 2010 03:46:34 +0000 (UTC) Received: by gxk24 with SMTP id 24so3297243gxk.13 for ; Tue, 31 Aug 2010 20:46:34 -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=ESjso0l4BlVv9MDVpnEDtTum8jYqk3ZI9FbczJCe6qQ=; b=RCRro56bRYZK/YPwuq5mf5Y3ppoBSmOCbXpuJnRf+9R6eRt5M2FsyDrVkP5nQFY3FO aKMImyyzs9J8CUYTlTqQi8KG3TM9dJ0vK+b4eNCDJCl+5wV+fSPBZ44C2lKum6jzE9hd 93mfiwH7eV7eEEJXZUguiAmh/Wh5Y9m+J8dyE= 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=F4gwNSzjcqM7/+U719VuklxbgypzpI2TNFfAdML3l1ULOdtmFVGsuvxbPiNf+ebGf1 LJkJog0poZnWQ/Br86ZyVoo/qu0BM2zPfTQH8uf687CX+ZyWFyljjHIY7zpI1QgJSJ5a 8ygZeKkcQXTa+q+DKazS8lPaUOqcn6hH32zq0= Received: by 10.150.136.10 with SMTP id j10mr4975413ybd.191.1283312794066; Tue, 31 Aug 2010 20:46:34 -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 q21sm9679045ybk.11.2010.08.31.20.46.32 (version=SSLv3 cipher=RC4-MD5); Tue, 31 Aug 2010 20:46:33 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C7DCC96.5030006@DataIX.net> Date: Tue, 31 Aug 2010 23:46:30 -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: bf1783@gmail.com References: <4C7D70CA.2070104@DataIX.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "b. f." , 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 List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 03:46:35 -0000 On 08/31/2010 20:06, b. f. wrote: > ? 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. My apologies I did not mean to infer that off-list mailing of those were a problem I just did not see it as needed, technically because math/blas will simply not build without a path to the gcc44 directory i.e -L/usr/local/lib/gcc44. Mailing you separately the contents what you asked for. Everything except the build errors as those are your standard linking errors for file not found. and can be reproduced by adding garbage to LDFLAGS i.e. -lslkdfksjdhf > > 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. > > 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. Specifically I use WITHOUT_PROFILE in src.conf(5) to ensure that those libraries do not exist on the system in question due to cases like this one. If I had not put that in there then I probably would not have been called to attention with this upgrade error and blindly would have had profiled libraries installed. I do have the libraries on hand if I should ever need profiling with the system libraries but I do not. I install these in a separate location for ease of use on testbeds. One example that I have of prevention in this case is the re-entrant version of libc. I once had to recompile libc and somehow ended up in the libc_r directory instead and after installing this lib manually for some reason or another it was being found first by every program on the system causing a slow down. Not knowing what caused that slowdown I began recompiling ports which I might add was terribly slow and after compiling 50 or so ports and having them then directly linked to libc_r I found the root cause of the problem ``libc_r'' not thinking twice about this I removed libc_r, crashed the system and had to SU in and edit libmap.conf to temporarily fix the problem until I could get all those ports recompiled again. So in short. To make sure this does not happen again on a client system re-entrant & profiling are disabled on a larger scale. The side effect is I find ports that blindly link to profiled libraries. So far I can only account for these two ports in ~1.5 years of use & that is about the time that the above problem arose and I decided to tend to it. > > 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. Here I did not define anything: pkg_delete -d blas-\* pkg_delete: file '/usr/local/lib/libblas_p.a' doesn't exist pkg_delete: couldn't entirely delete package (perhaps the packing list is incorrectly specified?) WITHOUT_PROFILE appears to work as it is supposed to by not adding that _p.a. Anyway I think Ive come to a better understanding of the issue that is really at hand with this case. It seems to me and I praise you guys/gals for being able to deal with it but there is simply to many knobs to account for things that could be handled by fewer knobs. The way I see it is WITH_ means use this and WITHOUT_ means do not use and can be contorted with operators like (!) in either form that already adds enough complexity to handle even the stickiest situations with ports but on top of that you have NOPROFILE NO_PROFILE etc... etc... and whatever else may be used to define (NO|DONT|DO|THAT|WITH|THESE) If this is for sheer compatibility then why aren't the *.mk files handling this instead of forcing it upon the maintainers. If you were to write a C program in this sense then gawd! only knows what the consequences would be so why are we doing it here?. Please do not take offense to any of this as I am just trying to understand why in a sea of Makefile's & define's. Regards, -- jhell,v