I noticed that libcpp/include/symtab.h includes obstack.h and puts a struct obstack in an exported structure:
/* An identifier hash table for cpplib and the front ends. */ struct ht { /* Identifiers are allocated from here. */ struct obstack stack; [...] typedef struct ht cpp_hash_table; [...] and then this structure is used in both libcpp/ and gcc/ (i.e., not opaque to gcc). E.g.,: ../gcc/stringpool.c:66: ident_hash = ht_create (14); ../gcc/stringpool.c:67: ident_hash->alloc_node = alloc_node; ../gcc/stringpool.c:68: ident_hash->alloc_subobject = stringpool_ggc_alloc; Since libcpp is configure/built as a separate library, and, it uses libiberty, this looks like a potential binary incompatibility. I.e., gcc/ sees one obstack definition, while libcpp sees another. I think that in practice the definitions end up being the same currently, as IIRC, Alan made sure to sync obstack.h between glibc / libiberty / gnulib's when he added the 64-bit support a while ago. In any case, it's quite possible that other incompatibilities will happen with other modules. I think the proper fix would be to adjust libcpp/Makefile.in to include headers from gnulib too sooner than later. libcc1/ is probably on the same boat. Thanks, Pedro Alves