On 23/06/16 12:18, Pedro Alves wrote: > gdb doesn't put that gnulib wrapper library at the top level, mainly > just because of history -- we didn't always have that wrapper > library -- and the fact that gdb/gdbserver/ itself is not at top > level either, even though it would be better moved to top level. > > See this long email, explaining how the current gdb's gnulib import > is set up: > > https://sourceware.org/ml/gdb-patches/2012-04/msg00426.html > > I suggest gcc reuses the whole of gdb's wrapper library and scripts: > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=tree;f=gdb/gnulib;h=cdf326774716ae427dc4fb47c9a410fcdf715563;hb=HEAD > > ... but put it in the top level instead.
if both gcc and binutils used a toplevel gnulib directory then shared tree build would have the same problem as libiberty has now: gcc and binutils can depend on different versions of libiberty and then the build can fail. as far as i know the shared tree build is the only way to build a toolchain without install (using in tree binutils) and it would be nice to fix that use case.
