Comment 5 for bug 1958909

> error: ‘LIBECAP_VERSION’ was not declared in this scope

Ah, LIBECAP_VERSION is not a "type", but a macro/constant defined in autoconf.h.

> the project being built does not [...] have the config.h.

But libecap (i.e., the library the project is using) does have autoconf.h. The adapter project should not prevent the inclusion of libecap's generated/installed autoconf.h.

When using autotools, this inclusion usually happens automatically because autotools usually define HAVE_CONFIG_H. When not using autotools, you have a few options, including:

1. Defining HAVE_CONFIG_H macro manually (so that libecap includes its own autoconf.h). In a sense, you would be telling libecap that it does have autoconf.h, which is true. Your adapter code does not need to use that macro, of course.

2. Including libecap autoconf.h manually, before any libecap files. This is kind of a hack because, ideally, you should not depend on how/when libecap includes that internal header file.

3. Defining the constants defined in libecap autoconf.h using compiler `-D` flags or equivalent. This is obviously a huge hack because you should not know which constants are defined in that internal header file.

Long-term, I suspect that libecap should not use HAVE_CONFIG_H at all; it should just assume that its (generated) autoconf.h file is always available. I do not know whether autotools recommend a different approach for installed libraries. I will edit and leave this bug report open to track that long-term change.

FWIW, it may be easier to build loadable modules using autotools and provided examples/samples than to figure out all the low-level linker/loader commands required for that on a given platform. YMMV.