Subject: bug#18947: unexpected EOF while looking for matching + patch

From: "Gary V. Vaughan" <[email-masked]>
Date: Thu, 13 Nov 2014 21:25:56 +0000

[resend to bug-Libtool for anyone else curious about this issue]

Hi Josef,

Thanks for the report.

> On Nov 13, 2014, at 12:09 PM, Josef Reidinger <[email-masked]> wrote:
> 
> Hi libtool developers,
> we also face this issue in opensuse with new version of libtool (2.4.3).
> 
> I debug a problem and it appear that problem is that we have in
> automake.am
> ACLOCAL_AMFLAGS = -I . -I `if test -d ./build-tools; then
> echo ./build-tools; else pkg-config --print-errors --variable=datadir
> yast2-devtools; fi`/aclocal
> 
> This cause double backticks in
> http://git.savannah.gnu.org/cgit/libtool.git/tree/libtoolize.in#n1400
> 
> To fix it, I verify that it helps to replace
> *,-I*) '$r'=`expr x$_G_arg : '\''x-I\(.*\)$'\''`; break ;;
> with
> *,-I*) '$r'=$(expr x$_G_arg : '\''x-I\(.*\)$'\''); break ;;
> 
> as ```` is problem, but $($()) is not problem or $(``) which is result
> if we do not modify Makefile.am.

Except that, as described in the Shellology section of the Autoconf manual, $() is not portable to modern Solaris or Irix, so we are stuck with backticks in Libtoolize which needs to run on those architectures.

That aside, I'm not at all convinced that multi-line backtick expressions in make macro expansions are well supported in any case.

If your project does not care about portability beyond GNU/Linux, you could use $() in your ACLOCAL_AMFLAGS. Or if you do need portability, you could either use a GNU make $(shell ...) extension to run the test in advance, or at configure time in configure.ac using AC_SUBST to inject the result into Makefile. You might even find that all the make implementations you target provide immediate macro assignment with ::= or != ; again to avoid adding backticks to your ACLOCAL_AMFLAGS.

HTH,
-- 
Gary V. Vaughan (gary AT gnu DOT org)