This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: Do not use glob on MinGW hosts
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