[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-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.