This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 26 July 2016 at 14:51, ayush goel <ayushgoel1610@gmail.com> wrote:
> On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez
> (lopezibanez@gmail.com) wrote:
>> Why the change from "fnmatch.h" to ?
>
> Gnulib doesn’t contain a header for fnmatch. It itself relies on
> glib’c fnmatch.h
I see two modules here:
https://www.gnu.org/software/gnulib/MODULES.html#module=fnmatch
https://www.gnu.org/software/gnulib/MODULES.html#module=fnmatch-gnu
Both of them generate a header file if the one from glibc is not
present or it is broken:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/fnmatch
Does GCC use the GNU extensions of fnmatch? If not, you probably only
need fnmatch; otherwise you may need to also import fnmatch-gnu.
>> 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.
Ah, good! You should mention this in future submissions (and in the wiki page).
> 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.
This is a necessary condition but not a sufficient condition.
Unfortunately, comparing the two functions in detail is still
necessary even if the tests succeed.
>> 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?
Well, you could find fnmatch.h in your system and remove/rename it
temporarily (also remove the libiberty versions under include/), then
try to bootstrap and see what happens. If the system fnmatch.h is not
used, the build system of gnulib should create a funmatch.h (check if
it is created, otherwise GCC found a different fnmatch.h).
Cheers,
Manuel.