Conflicting PACKAGE_NAME and other macros when using autotools - gcc

Question

When using autotools (with a config.h file) for both a library, and a software built on that library, the compiler complains about a redefinition of some macros (PACKAGE_NAME, PACKAGE_TARNAME and so on).
How can I prevent this?
The config.h file is needed in the library to propagate it's setting to the software that use it.
Right now I have a wrapper script library_config.h that includes the original config.h and provides defaults when the user is not using autotools, but even undefining the macros in that package I get the redefinition warning from gcc.
#ifndef LIB_CONFIG_H
#define LIB_CONFIG_H
#ifdef HAVE_CONFIG_H
# include "config.h"
# undef PACKAGE
# undef PACKAGE_BUGREPORT
# undef PACKAGE_NAME
# undef PACKAGE_STRING
# undef PACKAGE_TARNAME
# undef PACKAGE_VERSION
# undef VERSION
#else
# if defined (WIN32)
# define HAVE_UNORDERED_MAP 1
# define TR1_MIXED_NAMESPACE 1
# elif defined (__GXX_EXPERIMENTAL_CXX0X__)
# define HAVE_UNORDERED_MAP 1
# else
# define HAVE_TR1_UNORDERED_MAP 1
# endif
#endif
#endif
I believe the best option would be to have a library without that macros: How can I avoid the definition of PACKAGE, PACKAGE_NAME and so on in the library when using autotools?
EDIT: attemp to explain better.
When using the AC_CONFIG_HEADER macro in the configure.ac of the library I produce a config.h file with a lot of useful defines. This defines are useful for the library itself (both for it's compiled part and for its header files) AND for the client software. It's a pity however that the AC_CONFIG_HEADER mixes the useful macros that I need with other generic defines with fixed names (PACKAGE, PACKAGE_NAME) that clash when autotools are used also for the client software configuration.

Answer 1

If your application might dynamically link to the library, it makes no sense to have the static strings from the library statically built into the application.
Otherwise, you might want to look for ax_prefix_config_h.m4.
I would still just try to avoid installing a config.h file and define the library's API without resorting to config.h:
/* library.h */
const char library_version[];
/* library.c */
#include "library.h"
#include "config.h" /* the library's config.h */
const char library_version[] = PACKAGE_VERSION;
/* application.c */
#include "library.h"
#include "config.h" /* the application's config.h */
int main()
{
print("This is app version %s.\n", PACKAGE_VERSION);
print("The library is version %s\n", library_version);
return 0;
}
Make sure that the public library header files do not #include "config.h", and that the library does not install its config.h.

Answer 2

You should be able to designate the library as a "subpackage" of the software by calling AC_CONFIG_SUBDIRS([library]) in the software's configure.ac. That should eliminate the conflicts, and the settings from the top-level configure will still propagate down to the subpackage.
Here is the link to the page of the Autoconf manual describing this feature: http://www.gnu.org/software/hello/manual/automake/Subpackages.html