* [Bug general/4345] Logic in frysk-common.ac to determine 64-bit library location is flawed
2007-04-11 2:06 [Bug general/4345] New: Logic in frysk-common.ac to determine 64-bit library location is flawed kris dot van dot hees at oracle dot com
2007-04-11 2:48 ` [Bug general/4345] " cagney at redhat dot com
@ 2007-04-11 3:18 ` kris dot van dot hees at oracle dot com
2007-04-12 4:53 ` cagney at redhat dot com
2007-04-12 11:19 ` kris dot van dot hees at oracle dot com
3 siblings, 0 replies; 5+ messages in thread
From: kris dot van dot hees at oracle dot com @ 2007-04-11 3:18 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug general/4345] Logic in frysk-common.ac to determine 64-bit library location is flawed
2007-04-11 2:06 [Bug general/4345] New: Logic in frysk-common.ac to determine 64-bit library location is flawed kris dot van dot hees at oracle dot com
` (2 preceding siblings ...)
2007-04-12 4:53 ` cagney at redhat dot com
@ 2007-04-12 11:19 ` kris dot van dot hees at oracle dot com
3 siblings, 0 replies; 5+ messages in thread
From: kris dot van dot hees at oracle dot com @ 2007-04-12 11:19 UTC (permalink / raw)
To: frysk-bugzilla
------- 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.
^ permalink raw reply [flat|nested] 5+ messages in thread