PKG_CHECK_MODULES not working in Solaris

[Kaushik BV]

Hi all,

I am a newbie w.r.t to auto-tools. Searched for an answer in the list was
not able to find one, please direct me to the right list if the following
question is not appropriate.

My project requires dependency of `libxml2` am using autotools to check the
dependencies & install the same. I declare the dependency of using the
following macro in configure.ac

echo -n "checking if libxml2 is present... "

PKG_CHECK_MODULES([LIBXML2], [libxml-2.0 >= 2.6.19],
[echo "yes (features requiring libxml2 enabled)"
AC_DEFINE(HAVE_LIB_XML, 1, [define if libxml2 is present])],
[echo "no"] )

The macro works as desired in `GNU/Linux`.

But somehow it fails in `Solaris` with the following error

checking if libxml2 is present... ./configure: line 11586: syntax error
near unexpected token `LIBXML2,'
./configure: line 11586: `PKG_CHECK_MODULES(LIBXML2, libxml-2.0 >=
2.6.19,'

Googled for a solution, most of them complain of `pkg-config` not being
installed. But in my test machine its actually installed, checked it by
executing the following command.

bash-3.00# pkg-config libxml-2.0 --modversion
2.6.23

Some suggestions would be welcomed.

[Eric Blake]

Post by Kaushik BV
But somehow it fails in `Solaris` with the following error
checking if libxml2 is present... ./configure: line 11586: syntax error
near unexpected token `LIBXML2,'
./configure: line 11586: `PKG_CHECK_MODULES(LIBXML2, libxml-2.0>=
2.6.19,'

That means that your aclocal.m4 (either hand-written, or as generated by
'aclocal' from automake) file did not include enough instructions to
have a definition of the macro PKG_CHECK_MODULES. Is your project using
automake? If so, it means that you were probably relying on automake's
search path of installed public .m4 files on one machine where the
pkg-config package had been installed, but on your Solaris machine,
automake is not set up to find that external macro by default.

Relying on external .m4 macros when rerunning aclocal (or autoreconf) is
always dangerous - it means you are dependent on what else is already
installed on your machine. Better is to copy the pkg-config .m4 file
that defined PKG_CHECK_MODULES into your project, so that the macro is
available for all people who autoreconf your package, even in cases like
your Solaris setup where pkg-config has not already been installed in
such a way that its public .m4 files are visible to automake.

Post by Kaushik BV
Googled for a solution, most of them complain of `pkg-config` not being
installed. But in my test machine its actually installed, checked it by
executing the following command.
bash-3.00# pkg-config libxml-2.0 --modversion
2.6.23

That says that the pkg-config binary is installed, but doesn't say
whether the public .m4 files provided by the pkg-config package are
located somewhere that automake will find them by default.

[Daniel Pocock]

Post by Eric Blake

Post by Kaushik BV
But somehow it fails in `Solaris` with the following error
checking if libxml2 is present... ./configure: line 11586: syntax error
near unexpected token `LIBXML2,'
./configure: line 11586: `PKG_CHECK_MODULES(LIBXML2, libxml-2.0>=
2.6.19,'

That means that your aclocal.m4 (either hand-written, or as generated by
'aclocal' from automake) file did not include enough instructions to
have a definition of the macro PKG_CHECK_MODULES. Is your project using
automake? If so, it means that you were probably relying on automake's
search path of installed public .m4 files on one machine where the
pkg-config package had been installed, but on your Solaris machine,
automake is not set up to find that external macro by default.
Relying on external .m4 macros when rerunning aclocal (or autoreconf) is
always dangerous - it means you are dependent on what else is already
installed on your machine. Better is to copy the pkg-config .m4 file
that defined PKG_CHECK_MODULES into your project, so that the macro is
available for all people who autoreconf your package, even in cases like
your Solaris setup where pkg-config has not already been installed in
such a way that its public .m4 files are visible to automake.

Post by Kaushik BV
Googled for a solution, most of them complain of `pkg-config` not being
installed. But in my test machine its actually installed, checked it by
executing the following command.
bash-3.00# pkg-config libxml-2.0 --modversion
2.6.23

That says that the pkg-config binary is installed, but doesn't say
whether the public .m4 files provided by the pkg-config package are
located somewhere that automake will find them by default.

Users of reSIProcate have also come across this problem since we started
using PKG_CHECK_MODULES

I think PKG_CHECK_MODULES is a good idea, but is there some way to give
a more helpful error to tell people to install the pkg-config package on
their system?

[Marcus Karlsson]

Post by Daniel Pocock
I think PKG_CHECK_MODULES is a good idea, but is there some way to give
a more helpful error to tell people to install the pkg-config package on
their system?

Not easily since there's a lot of different parts pointing fingers at
each other. Your error message is not actually from Autoconf but from
the shell, which in this case looks like bash. Other shells might give
you better or worse explanations.

Marcus

[Eric Blake]

Post by Daniel Pocock
I think PKG_CHECK_MODULES is a good idea, but is there some way to give
a more helpful error to tell people to install the pkg-config package on
their system?

Stick this in your configure.ac:

m4_pattern_forbid([PKG_*])

then anyone running autoconf on your package without the pkg-config m4
modules installed will get an earlier error at autoconf time flagging
the unexpanded macro, rather than a late error at configure execution of
a shell syntax error or unfound command.

[Daniel Pocock]

Post by Eric Blake

Post by Daniel Pocock
I think PKG_CHECK_MODULES is a good idea, but is there some way to give
a more helpful error to tell people to install the pkg-config package on
their system?

m4_pattern_forbid([PKG_*])
then anyone running autoconf on your package without the pkg-config m4
modules installed will get an earlier error at autoconf time flagging
the unexpanded macro, rather than a late error at configure execution of
a shell syntax error or unfound command.

I tried adding that just under AM_INIT_AUTOMAKE
https://github.com/resiprocate/resiprocate/blob/master/configure.ac

autoreconf now fails even if pkg-config is present, here is the output:

$ autoreconf -fi
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: copying file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
configure:1477: error: possibly undefined macro: PKGS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:16327: error: possibly undefined macro: ac_cv_env_PKG_CONFIG_set
configure:16333: error: possibly undefined macro: ac_cv_path_PKG_CONFIG
configure:16371: error: possibly undefined macro: ac_pt_PKG_CONFIG
configure:16376: error: possibly undefined macro:
ac_cv_path_ac_pt_PKG_CONFIG
configure:16508: error: possibly undefined macro: DEPS_PYTHON_PKG_ERRORS
autoreconf: /usr/bin/autoconf failed with exit status: 1

[Nick Bowler]

[...]

Post by Daniel Pocock

Post by Eric Blake
m4_pattern_forbid([PKG_*])
then anyone running autoconf on your package without the pkg-config m4
modules installed will get an earlier error at autoconf time flagging
the unexpanded macro, rather than a late error at configure execution of
a shell syntax error or unfound command.

I tried adding that just under AM_INIT_AUTOMAKE
https://github.com/resiprocate/resiprocate/blob/master/configure.ac
$ autoreconf -fi

[...]

Post by Daniel Pocock
configure:1477: error: possibly undefined macro: PKGS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:16327: error: possibly undefined macro: ac_cv_env_PKG_CONFIG_set
configure:16333: error: possibly undefined macro: ac_cv_path_PKG_CONFIG
configure:16371: error: possibly undefined macro: ac_pt_PKG_CONFIG
ac_cv_path_ac_pt_PKG_CONFIG
configure:16508: error: possibly undefined macro: DEPS_PYTHON_PKG_ERRORS
autoreconf: /usr/bin/autoconf failed with exit status: 1

m4_pattern_forbid([^PKG_]) should work a bit better (untested).

Cheers,

[Daniel Pocock]

Post by Nick Bowler
[...]

Post by Daniel Pocock

Post by Eric Blake
m4_pattern_forbid([PKG_*])
then anyone running autoconf on your package without the pkg-config m4
modules installed will get an earlier error at autoconf time flagging
the unexpanded macro, rather than a late error at configure execution of
a shell syntax error or unfound command.

I tried adding that just under AM_INIT_AUTOMAKE
https://github.com/resiprocate/resiprocate/blob/master/configure.ac
$ autoreconf -fi

[...]

Post by Daniel Pocock
configure:1477: error: possibly undefined macro: PKGS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:16327: error: possibly undefined macro: ac_cv_env_PKG_CONFIG_set
configure:16333: error: possibly undefined macro: ac_cv_path_PKG_CONFIG
configure:16371: error: possibly undefined macro: ac_pt_PKG_CONFIG
ac_cv_path_ac_pt_PKG_CONFIG
configure:16508: error: possibly undefined macro: DEPS_PYTHON_PKG_ERRORS
autoreconf: /usr/bin/autoconf failed with exit status: 1

m4_pattern_forbid([^PKG_]) should work a bit better (untested).

Thanks, that appears to work

[Eric Blake]

The autoconf manual doesn't mention any examples of actually
using m4_pattern_forbid. Yet this is the perfect macro for
avoiding the all-too-common failure mode of configure dying with:

checking if libxml2 is present... ./configure: line 11586: syntax
error
near unexpected token `LIBXML2,'
./configure: line 11586: `PKG_CHECK_MODULES(LIBXML2, libxml-2.0>=
2.6.19,'

for developers that forgot to install pkg-config. While we don't
necessarily advertise the use of PKG_CHECK_MODULES, it is a
common enough situation that the manual should make it easier to
help developers learn about missing third-party macros.

Based on a mailing list report by Daniel Pocock:
http://lists.gnu.org/archive/html/autoconf/2014-01/msg00030.html

* doc/autoconf.texi (Forbidden Patterns): Add examples.

Signed-off-by: Eric Blake <***@redhat.com>
---

No wonder it took us a couple of iterations to give you the
right advice - we didn't have good documentation. This patch
should give us something to point the next person to, when
encountering a similar situation.

doc/autoconf.texi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 6c374c0..ae2987a 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -13373,6 +13373,18 @@ Forbidden Patterns
the authors of this documentation: input, such as macros, should be
documented by @samp{dnl} comments; reserving @samp{#}-comments to
document the output).
+
+As an example of a common use of this macro, consider what happens in
+packages that want to use the @command{pkg-config} script via the third
+party @code{PKG_CHECK_MODULES} macro. By default, if a developer checks
+out the development tree but has not yet installed the pkg-config macros
+locally, they can manage to successfully run @command{autoconf} on the
+package, but the resulting @file{configure} file will likely result in a
+confusing shell message about a syntax error on the line mentioning the
+unexpanded PKG_CHECK_MODULES macro. On the other hand, if
+@file{configure.ac} includes @code{m4_pattern_forbid([^PKG_])}, the
+missing pkg-config macros will be detected immediately without allowing
+@command{autoconf} to succeed.
@end defmac

Of course, you might encounter exceptions to these generic rules, for
@@ -13382,6 +13394,11 @@ Forbidden Patterns
@msindex{pattern_allow}
Any token matching @var{pattern} is allowed, including if it matches an
@code{m4_pattern_forbid} pattern.
+
+For example, gnulib uses @code{m4_pattern_forbid([^gl_])} to reserve the
+@code{gl_} namespace for itself, but also uses
+@code{m4_pattern_allow([^gl_ES$])} to avoid a false negative on the
+valid locale name.
@end defmac

@node Debugging via autom4te

[Eric Blake]

Post by Eric Blake
The autoconf manual doesn't mention any examples of actually
using m4_pattern_forbid. Yet this is the perfect macro for
checking if libxml2 is present... ./configure: line 11586: syntax error
near unexpected token `LIBXML2,'
./configure: line 11586: `PKG_CHECK_MODULES(LIBXML2, libxml-2.0>=
2.6.19,'
for developers that forgot to install pkg-config. While we don't
necessarily advertise the use of PKG_CHECK_MODULES, it is a
common enough situation that the manual should make it easier to
help developers learn about missing third-party macros.
http://lists.gnu.org/archive/html/autoconf/2014-01/msg00030.html
* doc/autoconf.texi (Forbidden Patterns): Add examples.
---
No wonder it took us a couple of iterations to give you the
right advice - we didn't have good documentation. This patch
should give us something to point the next person to, when
encountering a similar situation.

No comments, so I pushed this.