Re: [PATCH] Include _CRTIMP in _putenv() declaration in EXE wrapper sources.

[Vadim Zeitlin]

Charles Wilson <libtool <at> cwilson.fastmail.fm> writes:

> On 6/23/2011 5:34 AM, Vadim Zeitlin wrote:
> > Re-declaring _putenv() without _CRTIMP in strict ANSI mode when using
> > MinGW resulted in a warning because of a conflict with the previous
> > declaration that did use _CRTIMP.
> > 
> > Simply add _CRTIMP to our declaration to avoid it.
> 
> > -int _putenv (const char *);
> > +_CRTIMP int _putenv (const char *);
> 
> Probably should also add __cdecl (for correctness, not warning
> suppression) in case the user has done a -mrtd.
> 
> _CRTIMP int __cdecl _putenv (const char*);

 Sorry for the delay, I left aside my struggles with libtool for some time,
but am getting back to it now as I'd really like to not have to return to
this again later.

 It's not totally clear to me if I should make this trivial change myself
or whether this would be done by whoever applies the patch? FWIW I clearly
agree that __cdecl should be there, I just didn't think about -mrtd case.


> However, no need for __MINGW_NOTHROW, I think, because gcc does not
> appear to give this warning when "redeclarations" only differ by missing
> attributes (in this case, __attribute__ ((__nothrow__)) ).

 I didn't even realize that this was relevant for C code. Anyhow, none of
the versions I tested with warn about it (although I'm pretty sure that it
would warn in C++).

> The larger issue, of course, is that we need to implement
> LT_WRAPPER_CFLAGS variable (*), that strips out warning flags and
> especially -Werror and its other-compiler analogues from the user's
> C[,PP,XX]FLAGS -- otherwise, we will continue to hit this "problem" over
> and over.
> 
> This is the third or fourth time we've had to update the c-wrapper code
> for similar issues.

 I definitely agree that this would be the right approach but I'm afraid
I'm not qualified enough to do it in proper way (mostly because I have no
idea what would such proper way be). So for now I'd just like to fix this
particular problem and hope that no more others arise.

> (*) Dunno what the correct name should be.  LT_CFLAGS_FOR_BUILD or
> similar is /wrong/, because the wrapper is actually built for $host.

 I might be missing something but what's wrong with LT_WRAPPER_CFLAGS? It
seems pretty descriptive and clear to me.

 Thanks,
VZ