Re: libnjb.h configure issues.

[Akim Demaille]

| I received the following message while compiling gnomad2 for Linux, which 
references the libnjb library.  I don't understand why I was told to send this 
issue to you, but I will send you the message anyway.  Here is the message that 
instructed me to mail you.
| When running "configure --prefix=/usr/local" for gnomad2, I receive this 
message:
| configure: WARNING: libnjb.h: present but cannot be compiled
| configure: WARNING: libnjb.h: check for missing prerequisite headers?
| configure: WARNING: libnjb.h: proceeding with the preprocessor's result
| configure: WARNING:     ## ------------------------------------ ##
| configure: WARNING:     ## Report this to address@hidden ##
| configure: WARNING:     ## ------------------------------------ ##
| 
| Upon inspection of the config.log, it states:
| 
| configure:4382: checking libnjb.h usability
| configure:4395: g++ -c -g -O2  conftest.cc >&5
| In file included from configure:4444:
| /usr/local/include/libnjb.h:310: parse error before `protected'
| /usr/local/include/libnjb.h:317: parse error before `protected'
| 
| Insode libnjb.h at line 310, it states:
| int NJB_Send_Track (njb_t *njb, const char *path, const char *codec, const 
char *title, const char *album, const char *genre, const char *artist, 
u_int32_t length, u_int32_t tracknum, const char *year, int protected, 
XferCallback *callback, void *data, u_int32_t *trackid);·
| 
| Inside libnjb.h at line 317, it states:
| int NJB_Replace_Track_Tag(njb_t *njb, u_int32_t trackid, const char *codec, 
const char *title, const char *album, const char *genre, const char *artist, 
u_int32_t length, u_int32_t tracknum, u_int32_t filesize, const char *fname, 
const char *year, int protected)
| 
| This leads me to believe that the problem is, the author chose to use a 
variable name of "protected" for an integer, but "protected" is a reserved word 
in the C++ language for protected members in Object Oriented programming for 
classes.
| 
| I don't know if I should be sending all this, but I was merely following 
instructions.  Please accept my apology if this is sent to the wrong source.
| 
| Fletch Hasues
| address@hidden

Please, report this to the package maintainers, as it's a configure.ac
problem.  The Autoconf 2.57 doc says:

      Previous versions of Autoconf merely checked whether the header was
   accepted by the preprocessor.  This was changed because the old test was
   inappropriate for typical uses.  Headers are typically used to compile,
   not merely to preprocess, and the old behavior sometimes accepted
   headers that clashed at compile-time.  If you need to check whether a
   header is preprocessable, you can use `AC_PREPROC_IFELSE' (*note
   Running the Preprocessor::).
   
      This scheme, which improves the robustness of the test, also requires
   that you make sure that headers that must be included before the
   HEADER-FILE be part of the INCLUDES, (*note Default Includes::).  If
   looking for `bar.h', which requires that `foo.h' be included before if
   it exists, we suggest the following scheme:
   
   
   AC_CHECK_HEADERS([foo.h])
   AC_CHECK_HEADERS([bar.h], [], [],
   [#if HAVE_FOO_H
   # include <foo.h>
   # endif
   ])