[Bug general/4345] Logic in frysk-common.ac to determine 64-bit library location is flawed

["kris dot van dot hees at oracle dot com" <sourceware-bugzilla@sourceware.org>]

------- 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'
<<truncated>>
$ 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.