This is the mail archive of the
mailing list for the GCC project.
Re: Importing gnulib into the gcc tree
* When resubmitting a patch, also add again the Changelog.
* Use '.diff' or '.patch' as an extension, so that mail readers can
open the file as text.
* Mention that you have a copyright assignment in place already (I'm
assuming you have one already, no?).
* Mention how you regression tested your changes (on which targets?)
* In the case of these changes, and as further testing, it would be
good if you tried locally to remove obstack.[ch] from libiberty to
make sure nothing in GCC is using it. I don't think we can actually
remove it because it may be used by other projects using libiberty,
however, as your first submission showed, it is not always evident
that everything in GCC is using the gnulib version.
On 8 July 2016 at 20:30, ayush goel <email@example.com> wrote:
> Yes, that’s correct. It has been moved before the libiberty library in the list now. Bootstrapped the system with the changes as well.
> PFA the updated patch
> Ayush Goel
> On 8 July 2016 at 2:29:04 AM, Manuel López-Ibáñez (firstname.lastname@example.org) wrote:
>> On 7 July 2016 at 13:48, ayush goel wrote:
>> > In order to show the setup works, I’ve replaced libiberty’s version by obstack by gnulib’s.
>> This was made possible by replacing the corresponding header file and then including
>> gnulib headers and gnulib static library in the build path required to compile gcc files.
>> Hi Ayush,
>> I'm not an expert on the build machinery, so this question might be
>> misguided: How do you know it is using the version in gnulib rather
>> than the one in libiberty? I see it uses gnulib's header file but:
>> # Dependencies on the intl and portability libraries.
>> LIBDEPS= libcommon.a $(CPPLIB) $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) \
>> - $(LIBDECNUMBER) $(LIBBACKTRACE)
>> + $(LIBDECNUMBER) $(LIBBACKTRACE) $(LIBGNU)
>> makes me think that the code in libiberty is found before the one in libgnu.