Bug 772999 - autoconf should install a config.site that favors lib64 on 64-bit machines
autoconf should install a config.site that favors lib64 on 64-bit machines
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: autoconf (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Pavel Raiskup
Fedora Extras Quality Assurance
:
Depends On: 772997 962837
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-10 11:14 EST by Eric Blake
Modified: 2017-10-26 10:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 772997
Environment:
Last Closed: 2013-06-17 09:55:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Blake 2012-01-10 11:14:45 EST
Description of problem:
Autoconf generates configure scripts which default to using /usr/lib when --prefix is /usr, according to the GNU Coding Standards.  But since Fedora prefers /usr/lib64 on 64-bit machines, that means _every single configure script_ has to use --libdir=/usr/lib64 when using --prefix=/usr.  Per the autoconf documentation, if Fedora would just install a config.site, then then this choice could be made _automatically_, saving users some hassle by picking the defaults appropriate for their choice of --prefix.

Version-Release number of selected component (if applicable):
autoconf-2.68-2.fc15.noarch

How reproducible:
100%

Steps to Reproduce:
1. For pretty much any autoconf-generated configure script, run './configure --prefix=/usr' and check what got chosen for $libdir.
2.
3.
  
Actual results:
Unless the package took special pains to inline some logic, libdir defaults to ${exec_prefix}/lib, rather than ${exec_prefix}/lib64 (with ${exec_prefix} defaulting to /usr).

Expected results:
On Fedora, --libdir should default to ${exec_prefix}/lib64, when --prefix is /usr, without the user having to remember this.

Additional info:
See the autoconf documentation: https://www.gnu.org/software/autoconf/manual/autoconf.html#Site-Defaults
Installing /usr/share/config.site with something akin to these contents is sufficient:

   # /usr/share/config.site for FHS defaults when installing below /usr,
   # and the respective settings were not changed on the command line.
   if test "$prefix" = /usr; then
     test "$sysconfdir" = '${prefix}/etc' && sysconfdir=/etc
     test "$sharedstatedir" = '${prefix}/com' && sharedstatedir=/var
     test "$localstatedir" = '${prefix}/var' && localstatedir=/var
     test "$libdir" = '${exec_prefix}/lib' && libdir='${exec_prefix}/lib64'
   fi

Such a file is not built by upstream autoconf, but logically belongs as a distro-specific add-on to the Fedora autoconf package.
Comment 1 Pavel Raiskup 2013-01-08 06:46:19 EST
Hi Eric, as you supposed to install not only /usr/lib64 related config.site and
your config.site includes also the FHS compliance part, I guess that it would be
nice to install this file on all architectures (including 32 bits).

I modified this scirpt a little to allow installing of this script on all
architectures:

| # This is the config.site file to satisfy FHS defaults when installing below
| # /usr.
| #
| # You may override this file by your config.site using the CONFIG_SITE env
| # variable.
| #
| # Note: This file includes also RHEL/Fedora fix for installing libraries
| # into "/lib/lib64" on 64bit machines.
|
| if test "$prefix" = /usr; then
|   test "$sysconfdir" = '${prefix}/etc' && sysconfdir=/etc
|   test "$sharedstatedir" = '${prefix}/com' && sharedstatedir=/var
|   test "$localstatedir" = '${prefix}/var' && localstatedir=/var
|
|   ARCH=`uname -m`
|   for i in x86_64 ppc64 s390x aarch64; do
|     if test $ARCH = $i; then
|       test "$libdir" = '${exec_prefix}/lib' && libdir='${exec_prefix}/lib64'
|       break
|     fi
|   done
| fi

Do you think that the check for 64 bit architectures is OK for Fedora/RHEL
purposes?  I don't want to keep two config.site files in git for both 32 and 64
bit archs as those files are almost the same.  I also don't want to patch the
32 bit version for 64 bit purposes...

Thanks,
Pavel
Comment 2 Eric Blake 2013-01-08 08:39:12 EST
Having a single config.site that works on both 32-bit and 64-bit platforms sounds great, and your approach of testing $ARCH against known 64-bit platforms seems sane to me.
Comment 3 Pavel Raiskup 2013-01-14 08:42:53 EST
Committed to f17, f18, f19 (rawhide) ~> MODIFIED
Comment 4 Fedora Update System 2013-01-14 09:04:09 EST
autoconf-2.68-6.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/autoconf-2.68-6.fc17
Comment 5 Fedora Update System 2013-01-14 21:33:46 EST
Package autoconf-2.68-6.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing autoconf-2.68-6.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-0821/autoconf-2.68-6.fc17
then log in and leave karma (feedback).
Comment 6 Fedora Update System 2013-01-16 14:21:32 EST
Package autoconf-2.68-7.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing autoconf-2.68-7.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-0821/autoconf-2.68-7.fc17
then log in and leave karma (feedback).
Comment 7 Fedora End Of Life 2013-01-16 20:55:22 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Jakub Jelinek 2013-01-21 17:28:12 EST
Ugh, this breaks gcc package build and guess many others too.  Definitely not appropriate for Fedora 18 and older in my eyes, and even for Fedora 19 it will need lots of testing, this isn't kind of change you just push without discussing this with FeSCo etc.
Using export CONFIG_SITE=NONE to work around this mess for now in gcc.spec, until this is settled.
Comment 9 Pavel Raiskup 2013-01-22 05:32:20 EST
(In reply to comment #8)
> Ugh, this breaks gcc package build and guess many others too.  Definitely
> not appropriate for Fedora 18 and older in my eyes, and even for Fedora 19
> it will need lots of testing, this isn't kind of change you just push
> without discussing this with FeSCo etc.
> Using export CONFIG_SITE=NONE to work around this mess for now in gcc.spec,
> until this is settled.

Hm, I see now that there will occur problems in spec files in %files sections.
It seems that doing the revert for f17/f18 is without discussion (not pushed to
stable yet).

I'll probably stop the config.site installation for a while even in Rawhide (if
nobody has a better idea) for a while.  There is reasonable step to grep
for all configured packages using the --prefix option during configure phase
and not using other config.site re-defined options.

Pavel
Comment 10 Eric Blake 2013-01-23 11:53:54 EST
Question - can we make config.site smart enough to know if it is being run by rpmbuild (do nothing) vs. a normal user (do the /usr/lib64 swap-out)?  That is, my understanding of why you are disabling config.site is to work around issues where there are existing rpms that are unprepared to have config.site auto-set several parameters.  But if rpmbuild always exports a witness environment variable, then you can write config.site so that if the witness variable is set, then we don't auto-set anything, so that rpms are unaffected but we still get the benefits of config.site outside of rpms.
Comment 11 Eric Blake 2013-01-23 11:56:22 EST
Or, for that matter, should rpmbuild be setting CONFIG_SITE=NONE for ALL packages, in order to override all config.site usage and making rpm builds reproducible no matter what a sysadmin has done to their local config.site?  In other words, I think that this autoconf patch to use config.site can be unconditional (for F19 and beyond only, so that it has appropriate time for testing), and that it is worth cloning a second bug against the toolchain used to build rpms to actually set CONFIG_SITE for all builds.
Comment 12 Pavel Raiskup 2013-01-23 13:44:01 EST
(In reply to comment #10)
> Question - can we make config.site smart enough to know if it is being run
> by rpmbuild (do nothing) vs. a normal user (do the /usr/lib64 swap-out)?
> That is, my understanding of why you are disabling config.site is to work
> around issues where there are existing rpms that are unprepared to have
> config.site auto-set several parameters.  But if rpmbuild always exports a
> witness environment variable, then you can write config.site so that if the
> witness variable is set, then we don't auto-set anything, so that rpms are
> unaffected but we still get the benefits of config.site outside of rpms.

Could be done probably.  I just looked into environment variables exported by
rpmbuild and I can't see rpmbuild's identification (at least on f17).  There
seems to be ugly usable $RPM_ prefixed variables.

  $RPM_OPT_FLAGS
  $RPM_PACKAGE_RELEASE
  $RPM_LD_FLAGS
  $RPM_PACKAGE_NAME
  $RPM_SOURCE_DIR
  $RPM_BUILD_ROOT
  $RPM_PACKAGE_VERSION
  $RPM_OS
  $RPM_DOC_DIR
  $RPM_BUILD_DIR
  $RPM_ARCH

(In reply to comment #11)
> Or, for that matter, should rpmbuild be setting CONFIG_SITE=NONE for ALL
> packages, in order to override all config.site usage and making rpm builds
> reproducible no matter what a sysadmin has done to their local config.site?
> In other words, I think that this autoconf patch to use config.site can be
> unconditional (for F19 and beyond only, so that it has appropriate time for
> testing), and that it is worth cloning a second bug against the toolchain
> used to build rpms to actually set CONFIG_SITE for all builds.

I like this idea (CONFIG_SITE=/dev/null).  Even the package maintainers would
be able to use config.site in specs by resetting the $CONFIG_SITE to be empty
variable.
Comment 13 Fedora End Of Life 2013-04-03 15:40:24 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 14 Pavel Raiskup 2013-06-17 09:55:41 EDT
As the bug #962837 was resolved rawhide, I'm giving this change a second
chance.  With the confidence that it is safe now — pushed & built RAWHIDE.

Note You need to log in before you can comment on or make changes to this bug.