Passing stderr to MinGW-compiled DLL?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Passing stderr to MinGW-compiled DLL?

Travis Spencer
Hi All,

I have ported some C code from *NIX to Windows. I am using MinGW to compile this port into a DLL. It all compiles and links without warning. I can run it and it works perfectly...or almost.

In some cases where I consume this DLL from an app written in Visual Studio 2013, I get this error:

Unhandled exception at 0x77E78E19 (ntdll.dll) in ConsoleApplication2.exe: 0xC0000005: Access violation writing location 0x00000014.

This exception is generated when I call this line of code in ConsoleApplication2.exe:

my_good_library_init(stderr, TRACE);

This function expects a FILE* and an enum indicating the log level the library should use. If no debugging should be done, the client can pass NULL instead of an open FILE. When I call it this way, there is no exception, and things work perfectly. Also, if I open a file (e.g., "C:\temp\log.txt") and pass that FILE* to the init function, it works as well.

Reading this thread[1], I thought it was because I was using the dynamically linked C run-time in the EXE and the statically linked run-time in my MinGW-compiled DLL because I am passing these flags to gcc when I link it:

-static-libgcc -static-libstdc++

I removed those two linker options, and add libgcc_s_dw2-1.dll to ConsoleApplication2.exe's PATH. The program ran still, but I continued to get the unhandled exception whenever passing stderr or stdout.

Can anyone help me figure out how I can pass stderr or stdout from my non-MinGW-compiled EXE to the MinGW-compiled DLL?

TIA!

--

------------------------------------------------------------------------------

_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Passing stderr to MinGW-compiled DLL?

Paul Moore
On 7 November 2014 22:55, Travis Spencer <[hidden email]> wrote:
> Can anyone help me figure out how I can pass stderr or stdout from my
> non-MinGW-compiled EXE to the MinGW-compiled DLL?

It sounds like your exe and dll are using different C runtimes. If
both are using a dynamically linked CRT, it's most likely that the
gcc-compiled DLL is using msvcrt.dll whereas the VC-compiled exe is
using msvcr100.dll or similar. You need to use the same CRT. I'm not
sure it's possible to make VC use msvcrt.dll, so you may have to force
gcc to use msvcr100.dll. -lmsvcr100 might work, but it still leaves
some references to msvcrt, which may cause issues.

Paul

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Passing stderr to MinGW-compiled DLL?

Eli Zaretskii
In reply to this post by Travis Spencer
> From: Travis Spencer <[hidden email]>
> Date: Fri, 7 Nov 2014 23:55:59 +0100
>
> I have ported some C code from *NIX to Windows. I am using MinGW to compile
> this port into a DLL. It all compiles and links without warning. I can run it
> and it works perfectly...or almost.
>
> In some cases where I consume this DLL from an app written in Visual Studio
> 2013, I get this error:
>
> Unhandled exception at 0x77E78E19 (ntdll.dll) in ConsoleApplication2.exe:
> 0xC0000005: Access violation writing location 0x00000014.
>
> This exception is generated when I call this line of code in
> ConsoleApplication2.exe:
>
> my_good_library_init(stderr, TRACE);
>
> This function expects a FILE* and an enum indicating the log level the library
> should use. If no debugging should be done, the client can pass NULL instead of
> an open FILE. When I call it this way, there is no exception, and things work
> perfectly. Also, if I open a file (e.g., "C:\temp\log.txt") and pass that FILE*
> to the init function, it works as well.

Don't pass stderr, pass instead some value that the DLL will interpret
to use its own stderr.

In general, it's not a good idea to pass 'FILE *' pointers to DLLs.
If you must pass file references, pass the Win32 handle object.

> Reading this thread[1], I thought it was because I was using the dynamically
> linked C run-time in the EXE and the statically linked run-time in my
> MinGW-compiled DLL because I am passing these flags to gcc when I link it:
>
> -static-libgcc -static-libstdc++

Run-time is much more than just libgcc and libstdc++.  It's the entire
msvcrt.dll (or, rather, the functions from it your program is using).
MinGW doesn't support static linking of run-time, because static
run-time libraries are not freely available on Windows systems, you
can only get them if you install Studio.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Passing stderr to MinGW-compiled DLL?

Travis Spencer
In reply to this post by Paul Moore
On Sat, Nov 8, 2014 at 12:17 AM, Paul Moore <[hidden email]> wrote:
It sounds like your exe and dll are using different C runtimes. If
both are using a dynamically linked CRT, it's most likely that the
gcc-compiled DLL is using msvcrt.dll whereas the VC-compiled exe is
using msvcr100.dll or similar.

That's exactly right, Paul. I checked with Dependency Walker, and found that the DLL was using msvcrt.dll and the EXE was using MSVCR120D.dll.
 
You need to use the same CRT. I'm not
sure it's possible to make VC use msvcrt.dll,

I only found some mentions on the Net of using a different Windows driver build system or some other funky stuff to do this. There's no way in Visual Studio (that I could find).
 
so you may have to force
gcc to use msvcr100.dll. -lmsvcr100 might work, but it still leaves
some references to msvcrt, which may cause issues.

I tried this with -L/C/Windows/System32 -lmsvcr120D, but got the same crash.

Thanks for the suggestions! REALLY appreciated.


------------------------------------------------------------------------------

_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Passing stderr to MinGW-compiled DLL?

Travis Spencer
In reply to this post by Eli Zaretskii
On Sat, Nov 8, 2014 at 8:51 AM, Eli Zaretskii <[hidden email]> wrote:
Don't pass stderr, pass instead some value that the DLL will interpret
to use its own stderr.

In general, it's not a good idea to pass 'FILE *' pointers to DLLs.
If you must pass file references, pass the Win32 handle object.

I am trying to change the original code as little as possible, but by changing the API to accept a HANDLE instead of a FILE*, I was able to make it work. With a little preprocessor magic, I was able to make it look like the API hadn't actually changed :-)

Thanks, Eli, for the pointers -- pun intended ;-)

------------------------------------------------------------------------------

_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe