From:	cvn AT interchain DOT nl (Kees van Veen)
Subject:	Re: [ANN] mingw32-egcs native dev toolchain
12 Nov 1997 03:39:01 -0800 :
Message-ID:	<34697221.7E34839.cygnus.gnu-win32@interchain.nl>
References:	<2 DOT 2 DOT 32 DOT 19971111165118 DOT 0096eb4c AT ma DOT ultranet DOT com>
Mime-Version:	1.0
To:	"Larry Hall (RFK Partners Inc)" <lhall AT rfk DOT com>
Cc:	gnu-win32 AT cygnus DOT com

Larry Hall (RFK Partners Inc) wrote:
> 
> At 11:46 AM 11/11/97 +0100, Kees van Veen wrote:
> >I'm not using mingw32, but b18 with Sergey's patches.
> >
> >I have another question though.
> >
> >A while ago I posted a message about getenv() not returning the values
> >of
> >my environment variables when called from a relocatable dll.
> >
> >I found out that if I call _getenv() instead of getenv() that problem
> >does not
> >occur. The same goes for execv(), execvp() and system(), to name a few.
> >It seems only the underscore functions export the environment.
> >
> >Can anybody explain why this is?
> >
> >I now use '#define getenv _getenv' etc to get around this, but is there
> >a way
> >to force the compiler/linker to do this for me?
> >
> >Regards,
> >Kees van Veen (cvn AT interchain DOT nl)
> 
> I won't state this definitively but I suspect you are calling the Win32
> function directly by using _getenv() as opposed to using the b18 wrapper.
> I don't know why the cygwin32 implementation of this function doesn't work
> right.  MS commonly puts an underscore in front of these function names, I
> believe to differentiate the MBCS versions of these function from the
> UNICODE (underscore functions being MBCS).  They then define the original
> function name to the MBCS or UNICODE function appropriately.
> 
> I think what you're doing will work although you might miss the cygwin32
> "flavoring" of the environment if what I think your getting with this holds
> true.

The strange thing is that this only happens when I have built a dll of
the
library.

Linking to a .a generated with ar gives me the 'normal' getenv() and
exec()'s

Also strange is that getenv() (without the underscore) called from
main() does the
right thing, whether I linked to a DLL or to a static library.

main.c
------
main()
{
	printf("HOME=%s\n", getenv("HOME");
	rout();
}
rout.c
------
rout()
{
	printf("HOME=%s\n", getenv("HOME");
}

If a relocatable DLL is built from rout.c and I link main.c to it I get
HOME=//C/
HOME=(null)

If I use ar to build rout.a from rout.c and I link main.c to it I get
HOME=//C/
HOME=//C/

I have also checked the values for the 'environ' global variable, they
differ as
well when I use a DLL (I saw in Sergey's sources that getenv() does a
search on the 'environ' variable).

The same goes for the exec()'s.

Any idea on how to automatically get the right functions? The idea of
having to
redefine system calls does not appeal to me.

Kees (cvn AT interchain DOT nl)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -