[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optimizing repeated calls to AC_TRY_LINK

From: Benoit Sigoure
Subject: Re: Optimizing repeated calls to AC_TRY_LINK
Date: Wed, 9 Jan 2008 23:51:10 +0100

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://;h=7e5098a) and I'd like to avoid

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.

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

  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

that can be used inside the ACTION-IF-* arguments of AC_COMPILE_IFELSE.


compiles PROGRAM, and only cleans up after the respective action is

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]