Re: [ANN] mingw32-egcs native dev toolchain

Re: [ANN] mingw32-egcs native dev toolchain

[Larry Hall (RFK Partners Inc)]

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@interchain.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.



Larry Hall                      lhall@rfk.com
RFK Partners, Inc.              (781) 239-1053
8 Grove Street                  (781) 239-1655 - FAX
Wellesley, MA, 02181

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

Re: [ANN] mingw32-egcs native dev toolchain

[Kees van Veen]

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@interchain.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@interchain.nl)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: [ANN] mingw32-egcs native dev toolchain

[Kees van Veen]

Gunther Ebert wrote:

> ...
> I don't think that it has anything to do with mingw32, since even the startup
> code of the relocated dll wouldn't be executed. The NT program loader seems
> to get messed up while trying to find the entry point address.
> 
>

I've had problems with running applications with more than one dll, but
for the
moment I use 'dllfix.exe' (see the mail archives) to get around these
startup problems.
I use the procedure found at

	http://www.cygnus.com/misc/gnu-win32/building-reloc-dlls.txt

with '-lc -lcygwin.a -lkernel32 -lc' as extra linker options. I somehow
cannot get it
to work with the Makefile.DLLs of Fergus Henderson, i.e. more than one
dll.


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@interchain.nl)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: [ANN] mingw32-egcs native dev toolchain

[Gunther Ebert]

Mumit Khan wrote:
> > However, there are some problems with relocating dlls: If I
> > have a program which uses 2 dlls (both dlls are created by gcc)
> > I get an error, the system complains about not being able to
> > initialize the application properly (NT40SP3). I didn't have
> > this problem with b18 (and mingw32), relocation of dlls worked
> > there. To proof this I loaded the application into gdb (great
> > work, the gdb port BTW) and the application got a segmentation
> > fault just after the system tried to relocate the second dll.
> > I guess the workaround is to specify a particular base address
> > for every dll that no relocation is necessary.
> > This would be acceptable to me.
> >
> 
> I'm not a win32 programmer and have no idea how to do what you just
> suggested. Is this something the end user (eg., you) needs to do, or
> something I need to fix in gcc/ld? There was something similar in the
> mailing list recently which I happened to ignore hoping that it won't
> be a problem in my case.
> 

The end user would have to specify the base address when linking the dll.
However, a fix in ld to avoid this would be great ...

> I'll take another look at mingw32 to make sure I'm not missing any hacks
> to avoid this problem. Any suggestions/insights welcome.
> 

I don't think that it has anything to do with mingw32, since even the startup
code of the relocated dll wouldn't be executed. The NT program loader seems
to get messed up while trying to find the entry point address.

> Mumit

Gunther
-- 

Gunther Ebert
iXOS Anwendungs-Software GmbH
Angerstrasse 40-42
D-04177 Leipzig

Phone : +49 341 48503-0
Fax   : +49 341 48503-99
E-mail: mailto:gunther.ebert@ixos-leipzig.de
www   : http://www.ixos-leipzig.de
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

[ANN] mingw32-egcs native dev toolchain

[Mumit Khan]

Latest snapshot uploaded to my egcs-related ftp area:

   ftp://ftp.xraylith.wisc.edu/pub/khan/egcs/mingw32

Play with it and see if it works for you. I'll have the source patches
next week.

Mumit
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".