This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH build/doc] Replacing libiberty with gnulib


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]