Subject: Re: [ANN] mingw32-egcs native dev toolchain
From: [email-masked] (Kees van Veen)

12 Nov 1997 03:39:01 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Larry Hall (RFK Partners Inc)" <[email-masked]>
Cc: [email-masked]

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 ([email-masked])
> 
> 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 ([email-masked])
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".