From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1146 invoked by alias); 12 Apr 2007 11:19:09 -0000 Received: (qmail 1041 invoked by uid 48); 12 Apr 2007 11:18:58 -0000 Date: Thu, 12 Apr 2007 11:19:00 -0000 Message-ID: <20070412111858.1040.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/msg00066.txt.bz2 List-Id: ------- Additional Comments From kris dot van dot hees at oracle dot com 2007-04-12 12:18 ------- (In reply to comment #3) > Can you please provide an example? Breaking the commands down showing the > output from each would also be very helpful. Sure. It's trivial to do so... In fact, a standard FC6 environment offers an almost erfect example: $ export PKG_CONFIG_PATH=/usr/share/pkgconfig $ pkg-config --debug 2>&1 Option --debug seen Error printing disabled by default, value of --print-errors: 0 Error printing disabled Adding virtual 'pkg-config' package to list of known packages Scanning directory '/usr/share/pkgconfig' Ignoring file '..' in search directory; not a .pc file Ignoring file '.' in search directory; not a .pc file File 'gnome-doc-utils.pc' appears to be a .pc file Will find package 'gnome-doc-utils' in file '/usr/share/pkgconfig/gnome-doc-util s.pc' File 'xml2po.pc' appears to be a .pc file Will find package 'xml2po' in file '/usr/share/pkgconfig/xml2po.pc' File 'gnome-icon-theme.pc' appears to be a .pc file Will find package 'gnome-icon-theme' in file '/usr/share/pkgconfig/gnome-icon-th eme.pc' File 'gtk-doc.pc' appears to be a .pc file Will find package 'gtk-doc' in file '/usr/share/pkgconfig/gtk-doc.pc' Scanning directory '/usr/lib64/pkgconfig' Ignoring file '.' in search directory; not a .pc file Ignoring file '..' in search directory; not a .pc file File 'gdk-2.0.pc' appears to be a .pc file Will find package 'gdk-2.0' in file '/usr/lib64/pkgconfig/gdk-2.0.pc' <> $ pkg-config --debug 2>&1 |awk -F '/' '/^Scanning.*pkgconfig.$/ { print $(NF - 1); exit; }'` share As you can see, in this case 'share' would be assigned to 'lib', which results in the following (next command): $ export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/$lib/frysk/pkgconfig $ echo $PKG_CONFIG_PATH /usr/share/pkgconfig:/usr/share/frysk/pkgconfig This is clearly wrong, since if Frysk were to be installed on my system (which it isn't), it sure wouldn't be in /usr/share/frysk. Moving on... Next there is the block of code that actually makes use of ${lib}: case "${libdir}:${lib}" in *64*:* ) # 64-bit in /usr/lib64, 32-bit in /usr/lib lib32dir=`echo "${libdir}" | sed s,64,,g` lib64dir="${libdir}" ;; *:*64* ) # 64-bit in /usr/lib, 32-bit in /usr/lib32 lib32dir="${libdir}32" lib64dir="${libdir}" ;; * ) # 32-bit in /usr/lib, 64-bit in /usr/lib64 lib32dir="${libdir}" lib64dir="${libdir}64" ;; esac By default, on my x86_64 FC^ system, libdir is '/usr/local/lib'. Continuing my example from above, we're left with lib being 'share'. The conditional above will therefore operate on input '/usr/local/lib:share' which does matches the final case only, and remarkably enough, based on bogus input, we actually get the *correct* result, being: lib32dir=/usr/local/lib lib64dir=/usr/local/lib64 However, if we do *NOT* set PKG_CONFIG_PATH manually to anything, and go through the sequence above we end up with lib being 'lib64'. In that case, the conditional operates on '/usr/local/lib:lib64', and the 2nd case is triggered, leaving us with the *wrong* result, being: lib32dir=/usr/local/lib32 lib64dir=/usr/local/lib This is wrong because x86_64 FC6 uses the convention of lib for 32-bit libraries, and lib64 for 64-bit libraries, as indicated as follows: $ file /lib/libcrypto.so.0.9.8b /lib/libcrypto.so.0.9.8b: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped $ file /lib64/libcrypto.so.0.9.8b /lib64/libcrypto.so.0.9.8b: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped I hope this clears up your confusion on what the bug report is about. Note that many other examples can be used to indicate the same problem, because the underlying flaw is truly the (ab)use of pkg-config to drive the 32-vs-64-bit logic, and the fact that the configure script is modifying the PKG_CONFIG_PATH environment variable behind the user's back, and the fact that the wrong thing happens for some (perfectly valid) settings of PKG_CONFIG_PATH. -- 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.