[Libcdio-devel] Warnings about _FILE_OFFSET_BITS. was: libcdio 0.83 release around Oct 27

[Thomas Schmitt]

Hi,

> > Independent of the particular operating system, it appears to be a mistake
> > to define system macros only after including system headers.
> > Since config.h does define such macros, it should be included as first.

> If you want to suggest a patch to make this work in the environment you
> encountered please do.

I tried now and have to realize that it is not easy.

These messages from the make run

  In file included from ../include/cdio/types.h:34,
                   from ../include/cdio/cdio.h:35,
                   from sample4.c:25:
  ../include/cdio/cdio_config.h:332:1: warning: "_FILE_OFFSET_BITS" redefined
  In file included from /usr/include/stdio.h:37,
                   from sample4.c:22:
  
/usr/gcc/4.3/lib/gcc/i386-pc-solaris2.11/4.3.3/include-fixed/sys/feature_tests.h:218:1:
 warning: this is the location of the previous definition

are caused by these lines in sample4.c

  #include <stdio.h>
  #include <string.h>
  #include <sys/types.h>
  #include <cdio/cdio.h>

in include/cdio/cdio.h there are no system headers included before
  #include <cdio/types.h>
also in include/cdio/types.h all is clear before
  #include <cdio/cdio_config.h>
which finally defines
  #define _FILE_OFFSET_BITS 64

So to silence the warning (which is not necessarily harmless),
i would "only" have to move the whole <cdio/cdio.h> before <stdio.h>.

Cough. Even if this causes no problem on my systems, one never knows
what other subtle side effects this might have.

A week before announced release is probably not the time to do such
daring things.


------------------------------------------------------------------
Ideas for a solution in the next development cycle:

One could simply move
   #include <cdio/cdio.h>
a few notches higher in the four source files which issue warnings
on 32 bit Solaris.
Then hope for the best and test.

---

If the autotools config file had precautions against double
inclusion, then one could simply include it in sample4.c et.al
before any other include line.

But, alas, there is nothing to see that would resemble these wise
lines in <cdio/cdio.h>
  #ifndef __CDIO_H__
  #define __CDIO_H__
  ...
  #endif /* __CDIO_H__ */

So first i would try to find out whether autotools can be talked
into doing this in its config file.

---

One could pull the system headers into <cdio/cdio.h>
  #include <stdio.h>
  #include <string.h>
  #include <sys/types.h>
and take care to include them only after <cdio/types.h>.
This solution might become cumbersome when other *.c files join the club
with their own inclusion needs.
  
---

One could analyze <cdio/cdio.h> and its subordinates whether
it is harmless to move its inclusion before the system headers.

---

I myself decided to include the autotools config header into each
of the *.c files of GNU xorriso and not in any *.h file.
Thus i am free to put it to the very start of the #include lists
in the *.c files.

But i count 128 *.c files in the git clone of libcdio. :(
 
------------------------------------------------------------------

Have a nice day :)

Thomas