octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnulib troubles


From: John W. Eaton
Subject: gnulib troubles
Date: Mon, 22 Mar 2010 19:10:53 -0400

On 22-Mar-2010, Jaroslav Hajek wrote:

| hi all,
| 
| after a while I tried to build with Intel C++ but the build failed on
| liboctave/lo-sysdep.cc.
| Eventually I tracked the problem down as follows:
| 
| 1. #include <fcntl.h> is done from lo-sysdep.cc, which points to 
libgnu/fcntl.h.
| 2. libgnu/fcntl.h does #include_next<fcntl.h> which references the
| system header.
| 3. The system fcntl.h #includes <sys/stat.h> which references the
| gnulib replacement.
| 
| The problem is that at point 3, the code inside system's fcntl.h is
| patterned like this:
| 
| extern "C" {
| ...
| #include <sys/stat.h>
| ...
| }
| 
| This causes the C++ definitions from gnulib
| 
| namespace gnulib { ...}
| 
| occur inside an extern "C" declaration, which confuses Intel C++
| (complains about duplicate decl). I'm not sure whether this is legal,
| but it surely a bad idea.
| I was able to manually work it around by the following change to 
libgnu/fcntl.h:
| 
| --- a/fcntl.h 2010-03-22 10:25:11.000000000 +0100
| +++ b/fcntl.h 2010-03-22 10:25:02.000000000 +0100
| @@ -43,7 +43,9 @@
|  # include <sys/stat.h>
|  #endif
|  /* The include_next requires a split double-inclusion guard.  */
| +#define __need_system_sys_stat_h
|  #include_next <fcntl.h>
| +#undef __need_system_sys_stat_h
| 
|  #ifndef _GL_FCNTL_H
|  #define _GL_FCNTL_H
| 
| Is this a defect in gnulib? Or am I missing some settings?
| The system headers can be expected to include each other and I don't
| think it is a good idea to let them back-reference the gnulib headers,
| because this can lead to unpredictable problems. Gnulib should avoid
| it.
| 
| Maybe someone can comment on this before taking it to the gnulib mailing list?

I think the problem is that your system header file is surrounding the
#include <sys/stat.h> in an extern "C" block.  Or at least, I expect
that is what Bruno will say if you bring this up on the gnulib mailing
list.  But he may be able to suggest an appropriate solution for
gnulib, so I'd say report the problem to the gnulib maintainers.  He
may also say that Intel C++ is not a supported target, but I think it
would be best if we could support it if it doing so is not too much
trouble.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]