This is the mail archive of the
mailing list for the GCC project.
Re: Should we import gnulib under gcc/ or at the top-level like libiberty?
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Pedro Alves <palves at redhat dot com>, ayush goel <ayushgoel1610 at gmail dot com>, <gcc at gcc dot gnu dot org>
- Cc: <nd at arm dot com>, Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Thu, 23 Jun 2016 15:54:26 +0100
- Subject: Re: Should we import gnulib under gcc/ or at the top-level like libiberty?
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <etPan dot 576ad632 dot 63dc2d3 dot fa at Ayushs-MacBook-Pro dot local> <52bf0980-635e-3784-fa55-5157894dd6b8 at redhat dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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:
> I suggest gcc reuses the whole of gdb's wrapper library and scripts:
> ... 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.