Brian Dessent wrote: > [EMAIL PROTECTED] wrote: > >> Do you guys know if the problem with the access() standard library function >> has >> been worked around? >> Windows vista has an updated MSVCRT.DLL which returns false for access() >> using >> X_OK, this parameter was previously ignored, and returned true. MinGW / GCC >> does not work on Vista as a result. > > This is not a gcc issue in the slightest, it's a MinGW issue. And it > has been fixed there some time ago. Once you install the fixed MinGW > runtime and recompile gcc it works fine. There are binaries (at least > for the gcc.exe driver frontend, the primary one affected) posted on the > MinGW mailing list, but nobody has gotten around to posting rebuilt > binaries at the SF download area.
I'm disappointed to hear that MinGW made this change. As a MinGW user, I don't want MinGW to interpose anything between me and the MSVCRT libraries. I want MinGW to give me headers and import libraries for the Microsoft DLLs, with all their warts; nothing more, nothing less. Obviously, I don't have any say or control over MinGW; I'm just providing feedback as a long-term MinGW user. When I want a UNIX-like environment on Windows, I use Cygwin; when I want an alternative to VisualStudio for "native" Windows applications, I use MinGW. I'd prefer that code I write with MinGW also work with VisualStudio and vice versa. In my opinion, this is a GCC bug: there's no such thing as X_OK on Windows (it's not in the Microsoft headers, or documented by Microsoft as part of the API), and so GCC shouldn't be using it. The Vista runtime library chooses to issue an error when you set random bits in the mode provided to access, which is its privilege. There's a simple GCC change to fix this: have libiberty wrap the access function and mask out X_OK on non-Cygwin Windows. It's reasonable to put this change in libiberty, since it's job is to provide portability between systems. My two cents, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
