Re: Optimizing repeated calls to AC_TRY_LINK

[Benoit Sigoure]

On Jan 7, 2008, at 9:59 PM, Ralf Wildenhues wrote:

> Hello Benoit, and sorry for the long delay,

No problem ;o

> * Benoit Sigoure wrote on Tue, Nov 20, 2007 at 02:05:50AM CET:
> > Hi list,
> > I have a problem with my boost.m4 macro: it's too slow.  Boost is  
> > being
> > very unhelpful because it can be installed in many different  
> > places and
> > the libraries can have many different names.  So what I do is that I
> > create all the reasonably possible library names and then try to link
> > against each of them for each usual install path (/usr/local/lib,
> > /usr/lib, /opt/local/lib, C:/Boost/lib, etc.).  Even though I skip  
> > all
> > non existing paths and everything, I end up doing several calls to
> > AC_TRY_LINK before I correctly guess the right combination of  
> > flags to
> > use.  The macro is *much* more reliable than other existing macros  
> > but
> > embarrassingly slow.  Someone suggested something very simple: why  
> > not
> > compile conftest.o once and then try various combinations of flags to
> > link it?  After all, it's the compilation step that takes time (C++,
> > Boost, you know...).  Unfortunately, I think this is impossible to
> > achieve with current Autoconf, because all macros always endup  
> > cleaning
> > conftest.$ac_objext.  I had to work around this and fiddle with  
> > Autoconf
> > internals (Forgive me Lord For the wrongs I have done: http://
> > repo.or.cz/w/boost.m4.git?a=commit;h=7e5098a) and I'd like to avoid
> > that.
>
> First of all, I think you should reorder your tests in boost.m4.
> Make the loop
>
>  273     for boost_ldpath in "$boost_tmp_lib/lib" '' \
>  274              /opt/local/lib /usr/local/lib /opt/lib /usr/lib \
>  275              "$with_boost" C:/Boost/lib /lib /usr/lib64 /lib64
>
> the outermost one, if only for locality of reference.

I can't.  The goal is to find the most precise library name given the  
user request.  So when I try to find, say, libboost_foo-gcc41-mt- 
d-1_34_1, I want to search all the directories.  If this one can't be  
found, I'll try a less restrictive version of the library name (say,  
libboost_foo-gcc41-mt-d) and so on (until the canonic name  
libboost_foo).

While we're here, this has a very bad consequence.  I tend to link  
with the most precise -lflag (e.g. libboost_foo-gcc41-mt-d) which  
totally prevents the binaries to work after system updates, even  
though non-major updates remain ABI-compatible.  That seriously  
sucks.  Ideally, once I find a precise -lflag that works, I'd like to  
find the simplest -lflag that corresponds to the same shared object.   
If you have an idea as to how to implement this portably, let me know.

>   Then,
> if $boost_ldpath is nonempty, try a globbing match in that directory,
> and if that turns out empty, just skip all the other loops (a complete
> directory read is not cheap, but may just be a lot cheaper than  
> lots of
> compiles):
>
>   set x *boost_*
>   test $[]# = 1 && continue
>
> Report back if that breaks with a library naming scheme on some system
> (so that I don't recommend it again ;-).

Excellent idea.  I'll implement this.

> > What do you think?
> >   A. Autoconf can be enhanced to do this sort of thing (what  
> > should be
> > the interface?  who's in charge of cleaning conftest.$ac_objext?)
>
> Well, I suppose you could define an
>   AC_LINK_OBJECT([ACTION-IF-TRUE], [ACTION-IF-FALSE])
>
> that can be used inside the ACTION-IF-* arguments of  
> AC_COMPILE_IFELSE.
>
>   AC_COMPILE_IFELSE(PROGRAM, [ACTION-IF-TRUE], [ACTION-IF-FALSE])
>
> compiles PROGRAM, and only cleans up after the respective action is
> executed.
>
> AC_LINK_OBJECT may even get away with using $ac_link if it temporarily
> resets $ac_ext to $ac_objext, and empties $ac_fcflags_srcext for
> Fortran.  Dunno about Erlang, that may be a problem here.
> AC_LINK_OBJECT should not remove stuff generated by AC_COMPILE_IFELSE
> in order to facilitate being used several times in a row.
>
> Would you like to go for it?


Yes.  I don't know when, but be sure I'll give it a try as soon as I  
can.

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory