On 06/23/2016 03:54 PM, Szabolcs Nagy wrote: > 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.
Sharing/not-sharing vs top-level-or-not are orthogonal issues. As you note, combined tree conflicts are not a new issue introduced by the potintialy shared top level gnulib. A way to sort that out that crosses my mind immediately, would be give gcc's and binutil's copies different top level directory names, like say libiberty-gcc and libiberty-binutils or some such. You'd need to do the same to shared files in the include/ directory, and probably others that I'm not recalling off hand. So if we wanted to aim for that, we could call the new toplevel directory gnulib-gcc or some such. IMO, combining gcc and binutils trees of different enough vintage can't be guaranteed to work, so my suggestion is to treat that as "it hurts when I do this; then don't do that". Frankly, the idea of sharing a single gnulib import between gcc and binutils-gdb scares me a bit, because on the gdb side we're used to only care about making sure gdb works when we need to think about importing a new module. Not that it happens all that often though; maybe once a year. But on the other hand, the idea of maintaining multiple gnulib copies isn't that appealing either. Considering that the long term desired result ends up with a libiberty that is no longer a portability library, but instead only an utilities library, then to get to that stage, the other programs in the binutils-gdb repo which rely on libiberty too, binutils proper, gas, ld, gold, etc., need to be converted to use gnulib as well. And then a single gnulib sounds even more appealing. In any case, we don't really _need_ to consider sharing right now. gcc can start slow, and import and convert to use gnulib modules incrementally, instead of having it import all the modules gdb is importing from the get go. Thanks, Pedro Alves
