MinGW, GCC Vista,
Hi, 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. Regards Craig This message was sent using IMP, the Internet Messaging Program.
Re: MinGW, GCC Vista,
[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. Brian
Re: MinGW, GCC Vista,
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
Re: MinGW, GCC Vista,
Mark Mitchell writes: >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. Strictly speaking, access() (or _access()) isn't a documented part of any Windows ABI. It's only documented as part of the C Runtime Library for Visual C++, a different product. This is an important distinction, while MinGW should support Windows APIs as documented by Microsoft, it's not ment to be compatable with Visual C++. MinGW does use the same runtime DLL as used by Visual C++ 6.0, but this is essentially just an implementation detail, not ment as a compatibility goal. There are a few of ways MinGW's runtime is incompatable with Visual C++ 6.0. One of those ways is that the MinGW headers define R_OK, W_OK and X_OK. That was a probably a mistake, but in order for the MinGW runtime to be compatibile with both previous implementations and Windows Vista I think this change makes sense. Ross Ridge
Re: MinGW, GCC Vista,
Mark Mitchell wrote:
> 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.
I may have overstated the nature of the change, as it still requires
#defining a symbol to get a change in behavior:
#ifdef __USE_MINGW_ACCESS
/* Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code. This will restore the
old behaviour */
static inline int __mingw_access (const char* __fname, int __mode)
{ return _access (__fname, __mode & ~X_OK); }
#define access(__f,__m) __mingw_access (__f, __m)
#endif
So the default behavior is still the broken wartyness of X_OK.
> 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.
There is a long precedent for MinGW implementing/augmenting the MSVCRT
interface in the form of libmingwex for C99 complex math for example.
> 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.
This is also true, so I suppose it's not entirely correct to say that
this is not a gcc issue in the slightest. This above should indeed go
into libiberty as the long term solution. But no change today will
affect the MinGW system compiler (gcc 3.4.5 with a large amount of local
patches) which must be rebuilt one way or another, either by a patched
/mingw/include/io.h or by auditing all the source code and removing
X_OK, and the former is clearly less work than the latter. And the
__USE_MINGW_ACCESS feature can apply to porting other arbitrary packages
to Vista, without any source auditing.
Brian
Re: MinGW, GCC Vista,
Ross Ridge wrote: > Mark Mitchell writes: >> 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. > > Strictly speaking, access() (or _access()) isn't a documented part of > any Windows ABI. It's only documented as part of the C Runtime Library > for Visual C++, a different product. This is an important distinction, > while MinGW should support Windows APIs as documented by Microsoft, > it's not ment to be compatable with Visual C++. MinGW does use the same > runtime DLL as used by Visual C++ 6.0, but this is essentially just an > implementation detail, not ment as a compatibility goal. There are a > few of ways MinGW's runtime is incompatable with Visual C++ 6.0. OK. Unfortunately, I guess that's not what I hoped MinGW is. :-) (Again, I'm not trying to be critical: I like MinGW, and it's not my place to say what it ought to be. I'm just giving feedback as a user.) To me, the fact that it uses the MSVCRT runtime library is very important, and the Visual C++ interoperability is important. In light of Brian's comment that: > I may have overstated the nature of the change, as it still requires > #defining a symbol to get a change in behavior: it may be that MinGW is more like what I hope: unless I define the special symbol, MinGW doesn't interpose anything between me and the runtime library -- except that it defines X_OK, which, as you say, may have been a mistake, but is certainly water under the bridge! As a user, I certainly have no objection to MinGW offering more than Visual Studio, in terms of things like libmingwex. But, I would like to perserve the ability to use MSVCRT in all its warty glory. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: MinGW, GCC Vista,
Mark Mitchell writes: >(Again, I'm not trying to be critical: I like MinGW, and it's not my >place to say what it ought to be. I'm just giving feedback as a user.) Well, it's no more my place to say what it ought to be. I'm basically just describing what MinGW is, a Win32 compiler like Borland C++, not a drop-in Visual C++ replacement like Intel's Win32 compiler. >To me, the fact that it uses the MSVCRT runtime library is very >important, and the Visual C++ interoperability is important. Using MSVCRT.DLL only makes MinGW's runtime mostly compatible with Visual C++ 6.0 (and I think 5.0). Newer versions of Visual C++ use different runtime libraries, so that interoperability is becoming less relevent over time. Ross Ridge
RE: MinGW, GCC Vista,
> -Original Message- > From: Brian Dessent [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 08, 2007 3:21 PM > To: Mark Mitchell > Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED] > Subject: Re: MinGW, GCC Vista, > > Mark Mitchell wrote: > > > 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. > > This is also true, so I suppose it's not entirely correct to say that > this is not a gcc issue in the slightest. This above should indeed go > into libiberty as the long term solution. I would have thought that too. For reference, there is this GCC bug report: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972> Eric Weddington
Re: MinGW, GCC Vista,
Although the file io.h from MinGW/include has a patch, I still have not be able to use effectively the new build of gcc. I build it from a latop with a semprom and execute it in a desktop pc with a core 2 duo. The result is the same every time, there is a problem installation and it tells that cc1 is not found. Have you already built gcc 3.4.5 and tested it in Vista64? Thanks. -- View this message in context: http://www.nabble.com/MinGW%2C-GCC-Vista%2C-tf3707859.html#a10427219 Sent from the gcc - Dev mailing list archive at Nabble.com.
