Re: putenv with mingw32

[Brian Dessent]

Sylvain Beucler wrote:

> I imported module 'putenv'.

Did you also add the stdlib module?

> /usr/src/t/freedink-1.08.20081207/cross/gnulib/lib/../../../gnulib/lib/putenv.c:107:
>  undefined reference to `_environ'
> /usr/src/t/freedink-1.08.20081207/cross/gnulib/lib/../../../gnulib/lib/putenv.c:120:
>  undefined reference to `_environ'
> /usr/src/t/freedink-1.08.20081207/cross/gnulib/lib/../../../gnulib/lib/putenv.c:126:
>  undefined reference to `_environ'
> ../gnulib/lib/libgnu.a(putenv.o): In function `_unsetenv':
> /usr/src/t/freedink-1.08.20081207/cross/gnulib/lib/../../../gnulib/lib/putenv.c:70:
>  undefined reference to `_environ'
> collect2: ld returned 1 exit status

MinGW implements access to 'environ' as a macro in stdlib.h, one which
gets the environment pointer through a function call.  However, that
macro is not enabled if __STRICT_ANSI__ is set, and -std=c99 sets
__STRICT_ANSI__.  So one workaround would be to drop -std=c99, or add
-U__STRICT_ANSI__ to CFLAGS but that seems rather lame.

The question becomes how to access environ without the macro. 
Apparently MSVCRT does export one (as __environ), and it works for me to
declare it as

extern __declspec(dllimport) char **_environ;

and then access it as _environ everywhere.  Sigh.  So you'd still need a
"#define environ _environ" in order to use it without the leading
underscore.   (I get linker errors when trying to use auto-import to
resolve it, which is why the explicit dllimport seems necessary.)

BTW, it seems wrong that putenv.c blindly declares "extern char
**environ".  Without -std=c99, and with the macro expansion this comes
out as

extern char **(*__p__environ());

...which I guess just redeclares a compatible prototype for the
function, but it's a little weird.  Without the macro it just results in
an undefined reference.

It seems like the 'environ' module is where this could be cleaned up,
but at the moment it looks like its only use is to detect and set
HAVE_DECL_ENVIRON, which doesn't really help here.

> I don't really understand where '_environ' comes from (this is not the
> '__environ' from gnulib with double '_') - as far as I understand
> mingw32 tend to add a '_' to lots of core functions for some reason.

PE/COFF targets have a leading underscore added to the assembler name of
every symbol, so any reference to 'foo' at the source level is '_foo' at
the object level.

Brian