This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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