On 08/10/2016 02:40 PM, ayush goel wrote:
> On 9 August 2016 at 2:20:59 PM, Pedro Alves (pal...@redhat.com) wrote:
> I wasn’t aware of this. Thanks for pointing this out.
> It’s strange however, I didn’t see anything failing while
> building/testing my system.
If I comment out the include on gdb, here's what I get:
g++ -g3 -O0 -I. -I/home/pedro/gdb/mygit/src/gdb
-I/home/pedro/gdb/mygit/src/gdb/common -I/home/pedro/gdb/mygit/src/gdb/config
-DLOCALEDIR="\"/opt/gdb/share/locale\"" -DHAVE_CONFIG_H
-I/home/pedro/gdb/mygit/src/gdb/../include/opcode
-I/home/pedro/gdb/mygit/src/gdb/../opcodes/..
-I/home/pedro/gdb/mygit/src/gdb/../readline/..
-I/home/pedro/gdb/mygit/src/gdb/../zlib -I../bfd
-I/home/pedro/gdb/mygit/src/gdb/../bfd
-I/home/pedro/gdb/mygit/src/gdb/../include -I../libdecnumber
-I/home/pedro/gdb/mygit/src/gdb/../libdecnumber
-I/home/pedro/gdb/mygit/src/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1
-pthread -I/usr/include/guile/2.0 -I/usr/include/python3.4m
-I/usr/include/python3.4m -Wall -Wpointer-arith -Wno-unused -Wunused-value
-Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body
-Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare
-Wno-write-strings -Wno-narrowing -Wformat-nonliteral -Werror -c -o gdb.o -MT
gdb.o -MMD -MP -MF .deps/gdb.Tpo /home/pedro/gdb/mygit/src/gdb/gdb.c
In file included from
/home/pedro/gdb/mygit/src/gdb/gnulib/import/pathmax.h:42:0,
from /home/pedro/gdb/mygit/src/gdb/common/common-defs.h:67,
from /home/pedro/gdb/mygit/src/gdb/defs.h:28,
from /home/pedro/gdb/mygit/src/gdb/gdb.c:19:
build-gnulib/import/unistd.h:135:3: error: #error "Please include config.h
first."
#error "Please include config.h first."
^
In file included from /home/pedro/gdb/mygit/src/gdb/gdb_wchar.h:53:0,
from /home/pedro/gdb/mygit/src/gdb/defs.h:51,
from /home/pedro/gdb/mygit/src/gdb/gdb.c:19:
build-gnulib/import/wctype.h:66:3: error: #error "Please include config.h
first."
#error "Please include config.h first."
^
In file included from
/home/pedro/gdb/mygit/src/gdb/gnulib/import/pathmax.h:42:0,
from /home/pedro/gdb/mygit/src/gdb/common/common-defs.h:67,
from /home/pedro/gdb/mygit/src/gdb/defs.h:28,
from /home/pedro/gdb/mygit/src/gdb/gdb.c:19:
build-gnulib/import/unistd.h:137:1: error: ‘_GL_INLINE_HEADER_BEGIN’ does not
name a type
_GL_INLINE_HEADER_BEGIN
^
build-gnulib/import/unistd.h:1894:1: error: ‘_GL_INLINE_HEADER_END’ does not
name a type
_GL_INLINE_HEADER_END
^
In file included from /home/pedro/gdb/mygit/src/gdb/gdb_wchar.h:53:0,
from /home/pedro/gdb/mygit/src/gdb/defs.h:51,
from /home/pedro/gdb/mygit/src/gdb/gdb.c:19:
build-gnulib/import/wctype.h:68:1: error: ‘_GL_INLINE_HEADER_BEGIN’ does not
name a type
_GL_INLINE_HEADER_BEGIN
^
> It’s strange however, I didn’t see anything failing while
> building/testing my system.
You're pulling in the unistd.h replacement module, and from above,
we see that that replacement header should trip on this.
I think the reason you don't trip on this, is here:
> +INCGNU = -I../gnulib -I$(srcdir)/../gnulib/import
Specifically, the "-I../gnulib" part. That looks wrong.
Here's what the gnulib build directory looks like on a gdb
build:
$ cd build/gdb/build-gnulib
$ ls
import config.cache config.h config.log config.status Makefile stamp-h1
$ ls import/
sys dirent.h math.h string.h wchar.h
alloca.h dirname-lgpl.o math.o stripslash.o wctype.h
arg-nonnull.h inttypes.h ref-add.sed strnlen1.o wctype-h.o
basename-lgpl.o libgnu.a ref-del.sed time.h
c++defs.h localcharset.o signal.h unistd.h
charset.alias Makefile stdio.h unistd.o
configmake.h malloca.o stdlib.h warn-on-use.h
So you want to point -I at these generated, replacement headers, not
the gnulib build dir root, which in gcc is simply gnulib/ instead of
build-gnulib/.
So again, here:
> +INCGNU = -I../gnulib -I$(srcdir)/../gnulib/import
"-I../gnulib" should instead be "-I../gnulib/import" to put gnulib's
generated replacement headers in the include path.
And then you should trip on the problem. And you'll make gnulib's
replacement headers actually replace something. :-)
Assuming I'm right, that is.
> Can gcc also adopt a similar approach? Include gnulib’s config.h in a
> single header file instead of including it in every function that uses
> it.
> Which header file would be the most suitable for this purpose(probably
> which is generically included by almost all the gcc functions)?
I think "system.h" would be the most suitable. It's already included
everywhere first thing. The gen* stuff might need something special.
Since you're problably going to use sed to patch the files, including
some new file instead of config.h should be about the same work.
Up to gcc maintainers to decide.
Thanks,
Pedro Alves
