From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30812 invoked by alias); 11 Apr 2007 03:18:54 -0000 Received: (qmail 30715 invoked by uid 48); 11 Apr 2007 03:18:37 -0000 Date: Wed, 11 Apr 2007 03:18:00 -0000 Message-ID: <20070411031837.30714.qmail@sourceware.org> From: "kris dot van dot hees at oracle dot com" To: frysk-bugzilla@sourceware.org In-Reply-To: <20070411030621.4345.kris.van.hees@oracle.com> References: <20070411030621.4345.kris.van.hees@oracle.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug general/4345] Logic in frysk-common.ac to determine 64-bit library location is flawed X-Bugzilla-Reason: AssignedTo Mailing-List: contact frysk-bugzilla-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: frysk-bugzilla-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00060.txt.bz2 List-Id: ------- Additional Comments From kris dot van dot hees at oracle dot com 2007-04-11 04:18 ------- (In reply to comment #1) > > 1) The first line will not have the desired result for any host where the > > PKG_CONFIG_PATH has a non-standard path at the beginning of the list, > > which is commonly done for local overrides. > > I'm not sure I follow. The intent here is to provide an additional system-like > default. If the user modifies PKG_CONFIG_PATH then the user's override should > take precident. The value of ${lib} is later used in the determination where 64-bit libraries are stored. But the line (as it stands) may very well result in lib being 'lib' even though the 64-bit libraries are in /usr/lib64. In fact, I have a machine here (64-bit FC6) for which configure happily decides that lib32dir is 'lib32' and lib64dir is 'lib', while the system has 32-bit libraries in /usr/lib and 64-bit libraries in /usr/lib64. So, perhaps this assignment to lib is simply being (ab)used wrongly later on? Also note that this use of pkg-config is highly dependent on the PKG_CONFIG_PATH directory list, although the result is used as a component in a strictly defined path (/usr/$lib/frysk/pkgconfig). So, if I set a directory at the beginning of PKG_CONFIG_PATH that does not match whatever convention you expect for naming directories that are bitwidth specific, this won't result in the desired setting anyway. > > > 2) The PKG_CONFIG_PATH environment variable should not require a specific > > Frysk component for building Frysk, given that we can (and should be able > > to) build Frysk on a system where Frysk is not yet installed. As such, > > there should not be any need to have this line in common/frysk-common.ac at > > all. > > On RHEL 4 the frysk.rpm first builds and then installs into /usr/lib/frysk newer > but unsupported gnome and other libraries that are prereq's to building frysk. > Consequently, for someone building CVS frysk from scratch, the recommended > approach is to first install the frysk.rpm (getting the prereq's for free :-) > and then build frysk. The key word here is 'recommended'. That is certainly not the only way (and perhaps not even the best way). It also seems rather distribution specific, which would be rather counterproductive for a project like Frysk, I think. Building using an RPM spec file should not constraint development builds. And I can definitely foresee situations where the installed Frysk may contain older versions of libraries compared to what a development version may depend on (as time goes on). Why would we want to build in a dependency where (as my systems clearly indicate) none is needed? I do Frysk builds all the time (literally), on a system where no /usr/lib*/frysk can be found. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4345 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.