[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Libcdio-devel] Duplicate C Preprocessor header includes (Was Re: libcdi
[Libcdio-devel] Duplicate C Preprocessor header includes (Was Re: libcdio 0.83 release around Oct 27, FreeBSD-8 test)
Thu, 20 Oct 2011 21:06:06 -0400
To sum up the situation and the solution that is now in git...
libcdio install <cdio/cdio_config.h>; it contains all of the C Preprocessor
values from config.h (created by configure).
This header can be used to consult exactly how libcdio was built. Initially
I had selected "interesting" values, but this became too hard to maintain.
One set of values that libdio needs internally is the BigEndian/LittleEndian
and it can get this from config.h or cdio_config.h. The former of course is
Some of the libcdio programs like the demo programs include config.h for the
usual reasons, e.g. do we have <unistd.h>?
And then the program would want to include <cdio.h> to get libcdio headers
because libcdio needs some of the same information like BigEndian value we
have a duplicate include.
The way I have changed libcdio to get around this, and applications using
libcdio should do the same is to use:
# include "config.h"
# define __CDIO_CONFIG_H__ 1
Defining __CDIO_CONFIG_H__ will make sure config_cdio.h doesn't try to
redefine preprocessor symbols.
Ok. But now what about the problem that there are common preprocessor
symbols in config_cdio.h that an application may want to define in a
different manner, like PACKAGE_NAME?
For this I've justed added yet another header, <cdio/cdio_unconfig.h> file
which will undefine any symbol that config.h defines. And now we bounce to
the problem that there may be symbols that are normally defined
(HAVE_UNISTD_H) and you want to keep that way, but others that you don't.
So here is what I suggest
// for cdio:
#include <cdio_unconfig.h> # remove *all* symbols libcdio defines
// Add back in the ones you want your program
The solution isn't the most simple or natural, but programming sometimes can
be difficult. If someone has a better solution, let me know.
Between cdio_config.h and cdio_unconfig.h and all the fact that almost all
headers** define a symbol to indicate they have been included, I think there
is enough mechanism to cover any situation that may arise.
** <cdio_unconfig.h> is one of the few headers that doesn't set a
preprocessor symbol: it does its thing every time it is #included
On Thu, Oct 20, 2011 at 6:02 PM, Thomas Schmitt <address@hidden> wrote:
> i now built GNU xorriso with --enable-libcdio on FreeBSD 8.0-STABLE.
> It might be that the use of cdio_config.h is not compatible with the own
> autotools setup of applications which use libcdio:
> In file included from /usr/local/include/cdio/types.h:34,
> from /usr/local/include/cdio/cdio.h:35,
> from libburn/sg-libcdio.c:145,
> from libburn/sg.c:21:
> /usr/local/include/cdio/cdio_config.h:297:1: warning: "PACKAGE" redefined
> In file included from libburn/sg.c:9:
> libburn/../config.h:101:1: warning: this is the location of the previous
> Also clashing are PACKAGE_BUGREPORT, PACKAGE_NAME, PACKAGE_STRING,
> PACKAGE_VERSION, VERSION.
> xorriso does not make use of these macros. But it is not healthy
> that the libcdio config macros get included into the application.
> Have a nice day :)
- [Libcdio-devel] Duplicate C Preprocessor header includes (Was Re: libcdio 0.83 release around Oct 27, FreeBSD-8 test),
Rocky Bernstein <=