On Mon, Aug 30, 2010 at 14:42, Joshua Jensen <jjensen@xxxxxxxxxxxxxxxxx> wrote: > ----- Original Message ----- > From: Ævar Arnfjörð Bjarmason > Date: 8/29/2010 1:39 PM >> >> On Wed, Aug 18, 2010 at 18:32, Johannes Sixt<j6t@xxxxxxxx> wrote: >>> >>> On Mittwoch, 18. August 2010, Ævar Arnfjörð Bjarmason wrote: >>>> >>>> According to some further research at least FreeBSD and NetBSD have >>>> copied this GNU extension. You may find their versions easier to >>>> integrate. >>> >>> We already have a GNU fnmatch in compat/fnmatch. >> >> Do you have any plan to deal with this? I currently have this >> monkeypatch to build on Solaris: >> >> diff --git a/Makefile b/Makefile >> index 62d526a..079fae5 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -863,2 +863,4 @@ endif >> ifeq ($(uname_S),SunOS) >> + COMPAT_OBJS = compat/fnmatch/fnmatch.o >> + COMPAT_CFLAGS = -Icompat -Icompat/fnmatch >> NEEDS_SOCKET = YesPlease >> >> One way to deal with it would be a new NONGNU_FNMATCH=UnfortunatelyYes >> flag, or the fnmatch_icase() suggestion above which we could bundle >> and always use. But having next build on systems without GNU >> extensions would be preferrable. > > I am going to deal with this, but I haven't been around. I hope for some > time this week. Sure, no rush. I was just wondering whether you had some plan for it, or whether I should submit a patch to use the fallback on e.g. Solaris. > Short of duplicating fnmatch's code and renaming the function, I am not sure > how to make this play nice on all systems. I don't think duplicating the GNU (or *BSD) version into a compat/fnmatch.c would be a bad thing. See e.g. compat/snprintf.c. > You added COMPAT_OBJS above, but I think there is no linker > guarantee it will pick up compat/fnmatch/fnmatch.o over the C > runtime version? Perhaps the makefile is architected to do so. It's probably just an artifact of how the Solaris linker works, it doesn't go through the trouble of undefining an existing fnmatch symbol or anything. > The safest alternative is to allocate character buffers, lowercase the > filename and match arguments into those buffers, and pass them off to > fnmatch without any special flags. I don't like the idea of a double memory > allocation/free combo per each call to this function, but it would work. Is > anyone opposed to this approach? Just using the GNU extension and providing a fallback is probably cleaner and easier to maintain. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html