On Wed, 10 Sep 2008, Bruno Haible wrote:
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.
Except that the majority of desktop x86 PCs are running Microsoft Windows. ;-)
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.
Multilib support via libtool has been on the wish list for quite a while but implementing it is either a Big Job for libtool, or for the build environments which drive it. It seems to me that if libtool supports the ability to build/install for an "offset" directory that the rest of the responsibility can fall into the hands of autoconf and automake. There would need to be a configure framework which knows about the "standard" multilib conventions for each target and a build framework which builds all of them (or just the ones desired). Libtool is already complex enough so I think that most of the responsibility should be outside of libtool. Libtool needs to know how to store multilib objects/libraries in the build tree (perhaps via a user provided 'tag') , and how to install the correct ones when requested.
Bob ====================================== Bob Friesenhahn bfriesen@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
