Re: PATCH: Do not use glob on MinGW hosts

[Mark Mitchell <mark@codesourcery.com>]

Jakub Jelinek wrote:

>>This patch avoids the use of glob -- by assuming the the included file
>>is just a literal pathname rather than a glob pattern.  As #include's
>>in ld.so.conf are rare, and glob-pattern includes are rarer, this
>>seems like a satisfactory solution.  
> 
> 
> Well, they aren't that rare.
> E.g. every recent Fedora Core and Red Hat Enterprise Linux installation has
> include ld.so.conf.d/*.conf

Thanks for educating me!

(I'd actually checked one of our RHEL servers, and it's not set up that 
way.)

> So IMHO you should also check for M$ globbing like functions and use them.
> Does MinGW have fnmatch?  If yes, you could e.g. loop with
> FindFirstFile/FindNextFile and fnmatch on each filename, etc.

No, there's no fnmatch in MinGW.  (MinGW is just an interface to 
Microsoft's C library, and that library doesn't have fnmatch.)  However, 
there is "fnmatch" in libiberty, so we could use that.

And FindFirstFile/FindNextFile do accept patterns containing "*" and 
"?".  But, these functions only work within a single directory.  In 
contrast, "glob" can handle things like "/etc/*/*".  So, we would have 
to operate recursively.  Furthermore, it's not clear to me that 
Microsoft's pattern matching exactly matches GLIBC's in particular.

If we really want to make this portable, the way to make it work is to 
write our own implementation of glob which walks recursively through 
directories.  Then, we should use this implementation everywhere -- 
including on GNU/Linux itself -- so that we can be sure to get the same 
semantics.  The same implementation should also be used in the dynamic 
linker so that it is consistent too.  The easiest thing might be to try 
to adopt the GNU libc glob for libiberty, but that's certainly not going 
to be trivial, and we'll have to keep it in sync forever more.

I guess I'm inclined to let someone who needs to solve this problem 
solve it; for our current purposes, the solution I posted is satisfactory.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304