Hi -- This is a followup to a long-ago post. I recently had another problem building gnetlist, and learned more about this particular configure-time error. Therefore, I am posting my info here so that future Googlers can find it (and I can find it too since I won't remember it).
The problem occurs when the autotools don't expand the "PKG_CHECK_MODULES" macro, and then you try to ./configure. ./configure will then barf since it doesn't know what to do with this macro. I said: > Because I made changes in gattrib, I recently removed my local copy of > geda/devel/ and did a complete re-install of the CVS stuff (i.e. cvs > co geda/devel). I've had problems rebuilding the new stuff. I have > overcome the problems; I record my fixes here for future Googlers, as > well as to tip off the gEDA developers that some things might need > optimizing. Problems: > > 1. While configuring libgeda, configure bombs out, saying: > > checking for libgdgeda-config... no > ./configure: line 21421: syntax error near unexpected token > `libgdgeda,' > ./configure: line 21421: ` PKG_CHECK_MODULES(libgdgeda, libgdgeda > >= 2.0.15)' > make: *** [libgeda/config.h] Error 2 > > The problem is that autoconf isn't expanding the "PKG_CHECK_MODULES" > m4 macro during the "make reconfig" stage. It can't expand the macro > since it hasn't found the latest m4 directory. Configure for gschem > also bombs out due to a "GNU_GETTEXT" macro not being expanded. > Here's the fix: > > 1. Do "locate pkg.m4". > 2. Do "setenv ACLOCAL_FLAGS "-I <pkg.m4 directory>". > 3. Start building gEDA again. The new info is this: I should have been more explicit about what to do next. Here's what to do: 1. Do "locate pgk.m4". It should be someplace like /usr/share/aclocal/ (i.e. a system directory). If not, you may want to reinstall pgk-config. 2. Do 'setenv ACLOCAL_FLAGS "-I <pkg.m4 directory>"'. 3. Rerun aclocal. Better yet, rerun autogen.sh if it exists in your project directory. 4. Now you can do ./configure, and all that. Now back to your regularly scheduled programming. . . . . Stuart
