Re: Importing gnulib into the gcc tree
Hi Ayush,
On Mon, 18 Jul 2016, ayush goel wrote:
> I’m attaching a patch just containing the changes made in the /doc.
a couple of comments.
Index: gnulib-import.texi
===
--- gnulib-import.texi (nonexistent)
+++ gnulib-import.texi (working copy)
@@ -0,0 +1,16 @@
+@c Copyright (C) 1988-2016 Free Software Foundation, Inc.
For a new file, just 2016 should be fine.
+In order to import a new module from gnulib, the following steps need to be
executed, in order.
This line is a bit long; try to avoid more than 78 columns (80 being the
strict maximum). Same also below.
+Enter the name of the module to be imported in src/gnulib/update-gnulib.sh
under IMPORTED_GNULIB_MODULES.
That is a filename, thus @file{src/gnulib/update-gnulib.sh}.
And @code{IMPORTED_GNULIB_MODULES}.
+@item
+Run the file update-gnulib.sh. Usage: update-gnulib.sh
I'm not completely sure whether @file{update-gnulib.sh} or
@command{update-gnulib.sh}; feels like a corner case.
And @var{path-to-gnulib-repository}.
Invocations usally are marked up as
@smallexample
gcc -o out -O2 in.c plus.c
@end smallexample
With those changes, the documentation changes seem fine.
Gerald
Re: Importing gnulib into the gcc tree
Replies inline -- Thanks, Ayush Goel On 17 July 2016 at 9:44:27 PM, Manuel López-Ibáñez (lopeziba...@gmail.com) wrote: > On 16 July 2016 at 10:54, ayush goel wrote: > > Hi, > > Thanks for the feedbacks. > > > > —> I’m already configuring gcc with multiple languages and multilib enabled > > > > —> The changes have been bootstrapped and regression tested (complete > > check, make > -k -j20 check). > > > > —> As mentioned, I have locally removed obstack.[ch] from libiberty and > > built and tested > the entire thing. > > > > PFA the patch > > This sounds great to me, but I cannot approve it. I hope some of the > people who can will comment on it. > > One thing that I miss is documenting gnulib in doc/sourcebuild.texi. I’ve added gnulib as an entry in sourcebuild.texi > It would be good to document in particular how to add a new module. > GDB has: > https://sourceware.org/gdb/wiki/DeveloperTips#Updating_GDB.27s_import_of_gnulib > > but I think this info should be in sourcebuild.texi (or somewhere else > under doc/). > This wiki pages talks mostly of how to update the version of gnulib present inside the gdb directory. I’ve instead created a gnulib-import.texi file inside /doc with bullet points on how to import a new module. > I see several other mentions of libiberty in doc/, but some of them > may be just using libiberty as an example, thus not relevant. > Yes, there are several other mentions of libiberty (in contrib.texi, install.texi, invoke.texi etc) however these are not relevant to us. I’m attaching a patch just containing the changes made in the /doc. Once these are approved by the community, I’ll add them to the main patch and resubmit it. PFA > Cheers, > > Manuel. > gcc_doc.patch Description: Binary data
Re: Importing gnulib into the gcc tree
On 16 July 2016 at 10:54, ayush goel wrote: > Hi, > Thanks for the feedbacks. > > —> I’m already configuring gcc with multiple languages and multilib enabled > > —> The changes have been bootstrapped and regression tested (complete check, > make -k -j20 check). > > —> As mentioned, I have locally removed obstack.[ch] from libiberty and built > and tested the entire thing. > > PFA the patch This sounds great to me, but I cannot approve it. I hope some of the people who can will comment on it. One thing that I miss is documenting gnulib in doc/sourcebuild.texi. It would be good to document in particular how to add a new module. GDB has: https://sourceware.org/gdb/wiki/DeveloperTips#Updating_GDB.27s_import_of_gnulib but I think this info should be in sourcebuild.texi (or somewhere else under doc/). I see several other mentions of libiberty in doc/, but some of them may be just using libiberty as an example, thus not relevant. Cheers, Manuel.
Re: Importing gnulib into the gcc tree
Hi, Thanks for the feedbacks. —> I’m already configuring gcc with multiple languages and multilib enabled —> The changes have been bootstrapped and regression tested (complete check, make -k -j20 check). —> As mentioned, I have locally removed obstack.[ch] from libiberty and built and tested the entire thing. PFA the patch ChangeLog: 15-7-16 Ayush Goel * Makefile.def: Added gnulib as build & host library and dependency of all-gcc on gnulib * Makefile.in: regenerated * configure.ac: Added gnulib as build and host library * configure: regenerated * gcc/Makefile.in: Added path to gnulib static library (libgnu.a) and gnulib header files * gnulib: created directory * gnulib/Makefile.in: new file * gnulib/configure.ac: new file * gnulib/update-gnulib.sh: script to import gnulib modules using gnulib-tool * gnulib/import: created by update-gnulib.sh * gnulib/import/Makefile.in: imported from gnulib * gnulib/import/alignof.h: Imported from gnulib * gnulib/import/exitfail.c: Imported from gnulib * gnulib/import/exitfail.h: Imported from gnulib * gnulib/import/extra: Imported from gnulib * gnulib/import/extra/snippet: Imported from gnulib * gnulib/import/extra/snippet/_Noreturn.h: Imported from gnulib * gnulib/import/extra/snippet/arg-nonnull.h: Imported from gnulib * gnulib/import/extra/snippet/c++defs.h: Imported from gnulib * gnulib/import/extra/snippet/warn-on-use.h: Imported from gnulib * gnulib/import/gettext.h: Imported from gnulib * gnulib/import/m4: Imported from gnulib * gnulib/import/m4/00gnulib.m4: Imported from gnulib * gnulib/import/m4/absolute-header.m4: Imported from gnulib * gnulib/import/m4/extern-inline.m4: Imported from gnulib * gnulib/import/m4/gnulib-cache.m4: Imported from gnulib * gnulib/import/m4/gnulib-common.m4: Imported from gnulib * gnulib/import/m4/gnulib-comp.m4: Imported from gnulib * gnulib/import/m4/gnulib-tool.m4: Imported from gnulib * gnulib/import/m4/include_next.m4: Imported from gnulib * gnulib/import/m4/longlong.m4: Imported from gnulib * gnulib/import/m4/multiarch.m4: Imported from gnulib * gnulib/import/m4/obstack.m4: Imported from gnulib * gnulib/import/m4/off_t.m4: Imported from gnulib * gnulib/import/m4/ssize_t.m4: Imported from gnulib * gnulib/import/m4/stddef_h.m4: Imported from gnulib * gnulib/import/m4/stdint.m4: Imported from gnulib * gnulib/import/m4/stdlib_h.m4: Imported from gnulib * gnulib/import/m4/sys_types_h.m4: Imported from gnulib * gnulib/import/m4/unistd_h.m4: Imported from gnulib * gnulib/import/m4/warn-on-use.m4: Imported from gnulib * gnulib/import/m4/wchar_t.m4: Imported from gnulib * gnulib/import/obstack.c: Imported from gnulib * gnulib/import/obstack.h: Imported from gnulib * gnulib/import/stddef.in.h: Imported from gnulib * gnulib/import/stdint.in.h: Imported from gnulib * gnulib/import/stdlib.in.h: Imported from gnulib * gnulib/import/sys: Imported from gnulib * gnulib/import/sys_types.in.h: Imported from gnulib * gnulib/import/unistd.c: Imported from gnulib * gnulib/import/unistd.in.h: Imported from gnulib * gnulib/stamp-h1: generated Also note that I have a copyright assignment in place already. -- Thanks, Ayush Goel On 10 July 2016 at 9:35:27 PM, Manuel López-Ibáñez (lopeziba...@gmail.com) wrote: > Hi Ayush, > > Some suggestions: > > * 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. > > Cheers, > > Manuel. > > > On 8 July 2016 at 20:30, ayush goel 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 > > > > -- > > Thanks, > > Ayush Goel > > > > On 8 July 2016 at 2:29:04 AM, Manuel López-Ibáñez (lopeziba...@gmail.com) > > 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
Re: Importing gnulib into the gcc tree
On Sun, 2016-07-10 at 22:13 +0100, Manuel López-Ibáñez wrote: > On 10 July 2016 at 17:04, Manuel López-Ibáñez > wrote: > > Hi Ayush, > > > > Some suggestions: > > Also, it may be a good idea to configure with: > > --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --enable > -multilib > > so that you get as much coverage as possible. Please add "jit" to the list of enabled languages when testing big changes. It requires --enable-host-shared. It's probably worth testing both with and without --enable-host-shared, for that matter... (omitting jit for the latter). Dave
Re: Importing gnulib into the gcc tree
On 10 July 2016 at 17:04, Manuel López-Ibáñez wrote: > Hi Ayush, > > Some suggestions: Also, it may be a good idea to configure with: --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --enable-multilib so that you get as much coverage as possible. Cheers, Manuel.
Re: Importing gnulib into the gcc tree
Hi Ayush, Some suggestions: * 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. Cheers, Manuel. On 8 July 2016 at 20:30, ayush goel 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 > > -- > Thanks, > Ayush Goel > > On 8 July 2016 at 2:29:04 AM, Manuel López-Ibáñez (lopeziba...@gmail.com) > 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. >> >> Cheers, >> >> Manuel. >>
Re: Importing gnulib into the gcc tree
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 -- Thanks, Ayush Goel On 8 July 2016 at 2:29:04 AM, Manuel López-Ibáñez (lopeziba...@gmail.com) 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. > > Cheers, > > Manuel. > importgnulib_7_7 Description: Binary data
Re: Importing gnulib into the gcc tree
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. Cheers, Manuel.
Re: Importing gnulib into the gcc tree
Hey, As a first step of my GSOC project (https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported the gnulib library inside the gcc tree. I have created gnulib as a top level directory which contains the necessary scripts to import the modules. It also contains the necessary Makefile.in and configure.ac files. I have made the corresponding changes in the Makefile.def and configure.ac files, adding gnulib both as a build and host library, and subsequently regenerated the Makefile.in and configure files. 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. Used gdb’s scripts to import gnulib https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=tree;f=gdb/gnulib;h=cdf326774716ae427dc4fb47c9a410fcdf715563;hb=HEAD 7-7-16 Ayush Goel * Makefile.def: Added gnulib as build & host library and dependency of all-gcc on gnulib * Makefile.in: regenerated * configure.ac: Added gnulib as build and host library * configure: regenerated * gnulib: created directory * gnulib/Makefile.in: new file * gnulib/configure.ac: new file * gnulib/update-gnulib.sh: script to import gnulib modules using gnulib-tool * gnulib/import: created by update-gnulib.sh * gnulib/import/Makefile.in: imported from gnulib * gnulib/import/alignof.h: Imported from gnulib * gnulib/import/exitfail.c: Imported from gnulib * gnulib/import/exitfail.h: Imported from gnulib * gnulib/import/extra: Imported from gnulib * gnulib/import/extra/snippet: Imported from gnulib * gnulib/import/extra/snippet/_Noreturn.h: Imported from gnulib * gnulib/import/extra/snippet/arg-nonnull.h: Imported from gnulib * gnulib/import/extra/snippet/c++defs.h: Imported from gnulib * gnulib/import/extra/snippet/warn-on-use.h: Imported from gnulib * gnulib/import/gettext.h: Imported from gnulib * gnulib/import/m4: Imported from gnulib * gnulib/import/m4/00gnulib.m4: Imported from gnulib * gnulib/import/m4/absolute-header.m4: Imported from gnulib * gnulib/import/m4/extern-inline.m4: Imported from gnulib * gnulib/import/m4/gnulib-cache.m4: Imported from gnulib * gnulib/import/m4/gnulib-common.m4: Imported from gnulib * gnulib/import/m4/gnulib-comp.m4: Imported from gnulib * gnulib/import/m4/gnulib-tool.m4: Imported from gnulib * gnulib/import/m4/include_next.m4: Imported from gnulib * gnulib/import/m4/longlong.m4: Imported from gnulib * gnulib/import/m4/multiarch.m4: Imported from gnulib * gnulib/import/m4/obstack.m4: Imported from gnulib * gnulib/import/m4/off_t.m4: Imported from gnulib * gnulib/import/m4/ssize_t.m4: Imported from gnulib * gnulib/import/m4/stddef_h.m4: Imported from gnulib * gnulib/import/m4/stdint.m4: Imported from gnulib * gnulib/import/m4/stdlib_h.m4: Imported from gnulib * gnulib/import/m4/sys_types_h.m4: Imported from gnulib * gnulib/import/m4/unistd_h.m4: Imported from gnulib * gnulib/import/m4/warn-on-use.m4: Imported from gnulib * gnulib/import/m4/wchar_t.m4: Imported from gnulib * gnulib/import/obstack.c: Imported from gnulib * gnulib/import/obstack.h: Imported from gnulib * gnulib/import/stddef.in.h: Imported from gnulib * gnulib/import/stdint.in.h: Imported from gnulib * gnulib/import/stdlib.in.h: Imported from gnulib * gnulib/import/sys: Imported from gnulib * gnulib/import/sys_types.in.h: Imported from gnulib * gnulib/import/unistd.c: Imported from gnulib * gnulib/import/unistd.in.h: Imported from gnulib * gnulib/stamp-h1: generated -- Thanks, Ayush Goel On 27 June 2016 at 11:22:38 PM, Joseph Myers (jos...@codesourcery.com) wrote: > On Sat, 25 Jun 2016, ayush goel wrote: > > > Initially I have just imported the bcopy module from gnulib which will > > eventually replace gcc’s dependency on libiberty’s bcopy. > > GCC should not depend on bcopy. Any bcopy use is a bug and it should be > replaced by memcpy or memmove as appropriate. The poisoning in system.h > should prevent such uses from building in the first place. > >
Re: Importing gnulib into the gcc tree
On Sat, 25 Jun 2016, ayush goel wrote: > Initially I have just imported the bcopy module from gnulib which will > eventually replace gcc’s dependency on libiberty’s bcopy. GCC should not depend on bcopy. Any bcopy use is a bug and it should be replaced by memcpy or memmove as appropriate. The poisoning in system.h should prevent such uses from building in the first place. You should only import gnulib modules for functionality actually used in GCC - remembering that GCC now depends on at least a C++98 compiler and library, so it's unlikely that modules for ISO C90 functionality are actually relevant on any currently supported host or build system. For example, GCC uses obstacks, so the gnulib version of obstack is appropriate to replace the libiberty version. -- Joseph S. Myers jos...@codesourcery.com
Re: Importing gnulib into the gcc tree
I think, that you missed the patch file or it was removed from your email by server. 2016-06-25 14:06 GMT+02:00 ayush goel : > Hey, > As a first step of my GSOC project > (https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported the > gnulib library inside the gcc tree. I have created gnulib as a top level > directory which contains the necessary scripts to import the modules. It also > contains the necessary Makefile.in and configure.ac files. > I have made the corresponding changes in the Makefile.def and configure.ac > files, adding gnulib both as a build and host library, and subsequently > regenerated the Makefile.in and configure files. > > Initially I have just imported the bcopy module from gnulib which will > eventually replace gcc’s dependency on libiberty’s bcopy. > > > Bootstrapped/regtested on x86_64-linux and x86_64-apple-darwin15.5.0 > > > —— > > M src/Makefile.def > M src/Makefile.in > M src/configure > M src/configure.ac > A src/gnulib > A src/gnulib/Makefile.in > A src/gnulib/aclocal.m4 > A src/gnulib/config.in > A src/gnulib/configure > A src/gnulib/configure.ac > A src/gnulib/import > A src/gnulib/import/Makefile.am > A src/gnulib/import/Makefile.in > A src/gnulib/import/bcopy.c > A src/gnulib/import/dummy.c > A src/gnulib/import/extra > A src/gnulib/import/extra/snippet > A src/gnulib/import/extra/snippet/arg-nonnull.h > A src/gnulib/import/extra/snippet/c++defs.h > A src/gnulib/import/extra/snippet/warn-on-use.h > A src/gnulib/import/m4 > A src/gnulib/import/m4/00gnulib.m4 > A src/gnulib/import/m4/absolute-header.m4 > A src/gnulib/import/m4/gnulib-cache.m4 > A src/gnulib/import/m4/gnulib-common.m4 > A src/gnulib/import/m4/gnulib-comp.m4 > A src/gnulib/import/m4/gnulib-tool.m4 > A src/gnulib/import/m4/include_next.m4 > A src/gnulib/import/m4/off_t.m4 > A src/gnulib/import/m4/ssize_t.m4 > A src/gnulib/import/m4/strings_h.m4 > A src/gnulib/import/m4/sys_types_h.m4 > A src/gnulib/import/m4/warn-on-use.m4 > A src/gnulib/import/strings.in.h > A src/gnulib/import/sys_types.in.h > A src/gnulib/update-gnulib.sh > > > > -- > Thanks, > Ayush Goel > -- Jakub Sejdak Software Engineer Phoenix Systems (www.phoesys.com) +48 608 050 163
Importing gnulib into the gcc tree
Hey, As a first step of my GSOC project (https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported the gnulib library inside the gcc tree. I have created gnulib as a top level directory which contains the necessary scripts to import the modules. It also contains the necessary Makefile.in and configure.ac files. I have made the corresponding changes in the Makefile.def and configure.ac files, adding gnulib both as a build and host library, and subsequently regenerated the Makefile.in and configure files. Initially I have just imported the bcopy module from gnulib which will eventually replace gcc’s dependency on libiberty’s bcopy. Bootstrapped/regtested on x86_64-linux and x86_64-apple-darwin15.5.0 —— M src/Makefile.def M src/Makefile.in M src/configure M src/configure.ac A src/gnulib A src/gnulib/Makefile.in A src/gnulib/aclocal.m4 A src/gnulib/config.in A src/gnulib/configure A src/gnulib/configure.ac A src/gnulib/import A src/gnulib/import/Makefile.am A src/gnulib/import/Makefile.in A src/gnulib/import/bcopy.c A src/gnulib/import/dummy.c A src/gnulib/import/extra A src/gnulib/import/extra/snippet A src/gnulib/import/extra/snippet/arg-nonnull.h A src/gnulib/import/extra/snippet/c++defs.h A src/gnulib/import/extra/snippet/warn-on-use.h A src/gnulib/import/m4 A src/gnulib/import/m4/00gnulib.m4 A src/gnulib/import/m4/absolute-header.m4 A src/gnulib/import/m4/gnulib-cache.m4 A src/gnulib/import/m4/gnulib-common.m4 A src/gnulib/import/m4/gnulib-comp.m4 A src/gnulib/import/m4/gnulib-tool.m4 A src/gnulib/import/m4/include_next.m4 A src/gnulib/import/m4/off_t.m4 A src/gnulib/import/m4/ssize_t.m4 A src/gnulib/import/m4/strings_h.m4 A src/gnulib/import/m4/sys_types_h.m4 A src/gnulib/import/m4/warn-on-use.m4 A src/gnulib/import/strings.in.h A src/gnulib/import/sys_types.in.h A src/gnulib/update-gnulib.sh -- Thanks, Ayush Goel
