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
