Bob Friesenhahn wrote:
> There is no shortage of reasons to want to put libraries in different
> directories and autoconf/libtool should not stand in the way of
> freedom.
The proposal is to change the _default_ value of $(libdir). The --libdir
option still gives the user full freedom.
> > The fundamental oversight in this proposal is the desire to wanting to
> > distinguish 64bit and 32bit systems. multilibing actually is about
> > supporting several ABIs in parallel.
> >
> > 64/32 bit ABIs on Linux actually are a very special case.
>
> Right. There is also value to separate between some libraries which
> use the same ABI but with different run-time behavior. For example,
> libraries instrumented for profiling could go in a different
> directory.
Sure, there are several use-cases:
1) There are the 64/32 bit ABIs on Linux. By now this is probably affecting
the majority of the users of desktop x86 PCs.
2) There is the multilib support in gcc, as pointed out by Paolo and Ralf.
3) There is profiling and other variants.
Case 1) has high priority IMO because it affects a large portion of the users
who try the classical
./configure
make
make install
recipe and then discover that it does not produce working results.
If we can support case 2) as well, according to the patch Paolo submitted,
why not?
About case 3) I don't think we can do something meaningful, because
- There is no general convention where to install variants of libraries
compiled with profiling support,
- It is possible to mix profiled and non-profiled libraries and the user
may actually want to do this.
Remember that the user still has the --libdir option, to handle this case.
Bruno
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
