Howdy,
It is feeling like circular responsibilities to me.
So far, the circle seems unbroken. Let's start by
enumerating the ways of breaking it and then, perhaps,
figure out the easiest way. Currently, it is actually
broken by users having to know that for a particular
distribution, they have to specify the library directory
when they are building for the default architecture.
Probably not the best choice. Minimally, the "libdir"
should need specifying for the non-default architecture.
Here are some options:
1. Per autoconf documentation > *Note Site Configuration:: > Site Defaults
> Likewise, on platforms where 64-bit libraries are built by default,
> then installed in `/usr/local/lib64' instead of `/usr/local/lib', it is
> appropriate to install `/usr/local/share/config.site':
>
> # /usr/local/share/config.site for platforms that prefer
> # the directory /usr/local/lib64 over /usr/local/lib.
> test "$libdir" = '${exec_prefix}/lib' && libdir='${exec_prefix}/lib64'
the distributions should do something like this.
But that probably also belongs in /usr/share/config.site
since /usr/local is for a particular installation and
not an entire distribution.
The downsides:
A) that means distribution managers have to know and
understand obscure autoconf documentation. That
is also an unlikely burden -- unless autoconf
maintainers maintain a liaison with distributions.
That route has not proven to be maintainable.
B) It isn't clear to me that this test actually works.
I think the test is intended to be "is 'libdir' set
to the default value?" and that intent is not clear.
I think also the test needs to include, "is the target
architecture 64 bit?" If both are true, then change it.
The autoconf doc needs to be clearer.
C) Distributions are not doing this, though they can
be cajoled into it over time. Meanwhile, determining
the data model/library directory name parings isn't
really rocket science.
The upside: it is easier for autoconf.
2. autoconf can jump through however many hoops are necessary
to figure out the correct value for "libdir". It will be
able to query data model, platform, a ``--libdir'' option or
a libdir=xxx environment variable.
The downside: it is a nuisance
The upside, all distributions implementing use-lib64-for-the-default
"standard" need not change. However, they really ought to add
a /usr/share/autoconf-config.site file with some scripting
that can be run at the start of AC_OUTPUT.
3. continue requiring that someone who types "configure" must
a priori, know which platforms require "--libdir=xxx"
and which do not.
Upside: easier on distros and autoconf
Downside: it can lead to discussions like this.
On 12/20/10 07:22, Ralf Corsepius wrote:
> The latter is a system's internal implementation detail - If libtool
> can't avoid exposing these implicit details, it has to examine the tools
> being involved internal settings (In case of Fedora/RHEL: gcc).
Wherever the decision is made about selecting the value for libdir,
the code needs enhancement to include information about the data model
("architecture") being used. That isn't libtool code, I don't think.
Still, it is not as though libtool is disinterested either. After all,
it is not unreasonable to have one build construct both 32 and 64
bit binaries, so you cannot burn the information into the constructed
"libtool" script. However, a multi-data-model build is out of the
scope of this discussion because anybody doing such a thing had better
have a good understanding of how to specify such a beast to the build
tools. This discussion is about making it easy to get a correct
default installation without having to become an expert on the various
build tools.
> Wrt. autoconf: There have repeatedly been discussion on letting autoconf
> provide different defaults for libdir on 64bit targets, but ...
> ... besides that guessing on system defaults is difficult, do you
> realize that the setting autoconf provides are simply defaults, user
> will almost always have to change?
If the default build is 64 bit, why does it make sense that the
default library directory is the 32 bit library?
>>> I am sure of this: It needs to be minimized. If there are insurmountable
>>> problems in figuring out that the lib directory is /usr/lib64,
>>> then the builder has to supply it. I really doubt it is that hard to
>>> figure out though.
>>
>> If a distro insists on shipping 64-bit libraries under /usr/lib64, then
>> it would be in the distro's best interest to also ship a config.site
>> variable that defaults --libdir to the appropriate /usr/lib64 location.
>
> This isn't of much help on multi-arched architectures (such as Fedora/RHEL
> x86_64 systems), because any such default would only match to one of its
> supported architectures and be wrong on all others.
It would match the default. As I mentioned (or implied) above, if the
multi-data-model default is 32 bits, then the default library directory
should be for the 32 bit library. If the default is 64 bit, then the
default library directory darn well better be for the 64 bit libraries.
My mantra: go to some extra trouble to make it easier on your users.
Cheers - Bruce
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
