On 26 July 2016 at 19:21, ayush goel <ayushgoel1...@gmail.com> wrote: > On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez > (lopeziba...@gmail.com) wrote: >> On 25 July 2016 at 18:18, ayush goel wrote: >> > On top of the previously filed patch for importing gnulib (the link >> > isn’t available on the archive yet, however this contains some of the >> > information: >> > http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573) >> > now I have replaced another function from libiberty with the >> > corresponding version from gnulib. >> > Even though in both OSX and GNU/Linux, fnmatch is provided by the GNU >> > libc already, so the copy in libiberty is not used in your systems. >> > However since the objective is to replace whatever functions can be >> > leveraged by gnulib, these changes have been made. >> >> Why the change from "fnmatch.h" to ? > > Gnulib doesn’t contain a header for fnmatch. It itself relies on > glib’c fnmatch.h > >> >> Also, are the files in gnulib and libiberty semantically identical? >> The wiki page does not say anything about this. How did you check >> this? > > Well the online docs for libiberty and gnulib claim the same > definition for fnmatch. Apart from this I’ve manually gone through the > source code and they seem to be semantically similar. > Also the fact that the system builds fine and the tests also execute > fine could serve as a manifestation for the fact that they are > semantically same. >> >> GCC can run on other systems besides OSX and GNU/Linux, how can you >> test that your change does not break anything on those systems? >> > Well I have access to these two systems only. How would you suggest I > test my patches on all possible systems? Maybe building contrib/config-list.mk could help ? AFAIK, it will cross build the gcc tree for different targets, but not run the testsuite, however I could be wrong.
Thanks, Prathamesh > >> Cheers, >> >> Manuel. >> > > -Ayush
