* Ross Burton wrote on Tue, Apr 22, 2008 at 10:23:00PM CEST: > > I hope you can replicate this. :)
Yes, I can replicate it now. > I'm working on patches to remove the ./libtool calls from configure.ac, > but until they've landed those tests will fail. When you do this, be sure to also fix the configure.ac script to *not* *modify* deplibs_check_method, or export_dynamic, for that matter. IOW, these lines look like culprits: deplibs_check_method=`(./libtool --config; echo 'eval echo $deplibs_check_method') | sh` export_dynamic=`(./libtool --config; echo eval echo \\$export_dynamic_flag_spec) | sh` I don't understand in the first place why they are done this way, ignoring the fact for a moment that ./libtool doesn't exist yet (it exists the second time you run ./configure, which is why it worked for you then). One can simply eval `./libtool --config | grep "^deplibs_check_method="` OK. Since this is the second package where for a (long) moment I got really worried that we have our shell selection stuff messed up, but it then turns out that it's the package's configure.ac doing something we don't expect (and don't like ;-), I'm going to stop worrying, and start blaming packages earlier next time. Note that, even if we went the way suggested by Charles' patch, making AC_PROG_LIBTOOL be roughly equivalent to LT_INIT LT_OUTPUT which may have saved us in this case (I haven't checked), but which would not save us if the user later munges with, say, deplibs_check_method: we still regenerate ./libtool at config.status time and then use the then-current values of the variables. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
