Lorenzo Bettini <lorenzo.bett...@gmail.com> writes: > On 05/03/2011 01:11 PM, Lorenzo Bettini wrote: >> On 05/02/2011 02:59 PM, Bastien ROUCARIES wrote: >>> On Mon, May 2, 2011 at 12:02 PM, Lorenzo Bettini >>> <lorenzo.bett...@gmail.com> wrote: >>>> On 04/25/2011 06:36 PM, Bruno Haible wrote: >>>>> >>>>> Lorenzo Bettini wrote: >>>>>> >>>>>> on the manual I read >>>>>> >>>>>> "These Gnulib substitute header files rely on<config.h> being already >>>>>> included. Furthermore<config.h> must be the first include in every >>>>>> compilation unit. This means that to all your source files and likely >>>>>> also to all your tests source files you need to add an ‘#include >>>>>> <config.h>’ at the top. Which source files are affected? Exactly those >>>>>> whose compilation includes a ‘-I’ option that refers to the Gnulib >>>>>> library directory. " >>>>> >>>>> This paragraph is correct. >>>>> >>>>>> Would it be correct to put config.h only say in file1.cpp (and use the >>>>>> ‘-I’ option that refers to the Gnulib library directory for that file >>>>>> only), and not in file2.cpp and file3.cpp (where I don't use -I to >>>>>> refer >>>>>> to gnulib library directory), and then link all the 3 files >>>>>> together by >>>>>> also putting -lgnu? >>>>> >>>>> This will work find as long as data types defined in system headers >>>>> defined by >>>>> gnulib (such as structs, function pointers, pointers to socklen_t, >>>>> etc.) >>>>> are >>>>> not exchanged between file1.cpp on one side and file2.cpp and >>>>> file3.cpp on >>>>> the >>>>> other side. >>>>> >>>>> For example, if file1.cpp passes a 'struct stat' to file2.cpp >>>>> through some >>>>> function call or global variable, then you must be aware that the >>>>> 'struct >>>>> stat' >>>>> that file1.cpp sees is 64-bit safe and therefore larger than the 32-bit >>>>> 'struct stat' that file2.cpp sees. Similarly for 'struct >>>>> sched_param' in >>>>> <sched.h> and others. Typically this leads to crashes that are very >>>>> hard >>>>> to >>>>> debug because the source code suggests to you that the two 'struct >>>>> stat's >>>>> are the same when they are not. >>>> >>>> Thanks for the answer >>>> >>>> but what about libraries? >>>> For instance, I can live with including config.h in all .cpp library >>>> files, >>>> but I wouldn't add it to library header files. Header files are not >>>> referring to any struct defined in system header files of gnulib... >>>> at least >>>> I guess (basically my library header files only use string form C++ >>>> standard >>>> library)... would that be safe? >>> >>> What why bruce is trying to create libposix... >> >> does this mean that it is not safe to use gnulib as above? > > what I meant is "is it not safe to use gnulib in a library"?
I'm not sure I understand the question fully -- but gnulib is safe to use in a library, add a #include <config.h> to all your .c or .cpp files as the first non-comment and non-whitespace line. You shouldn't include config.h from any header file. /Simon
