mingw-users

[Mingw-users] atexit() & _onexit(): crt1 & dllcrt vs msvcrt.dll

[Jim B. <Ji...@JC...>]

Removing msvcrt.dll from the build also brings up problems with atexit()
and _onexit(), two functions that add a deliberate layer for msvcrt.dll
deficiencies.

Does anyone have a test that shows this problem?

I'm tinkering with making msvcr100.dll a drop-in replacement for
msvcrt.dll (no manifest req'd), and I'd like to determine if that's
fixed in msvcr100.dll.

Re: [Mingw-users] atexit() & _onexit(): crt1 & dllcrt vs msvcrt.dll

[Earnie <ea...@us...>]

Jim Bell wrote:
> Removing msvcrt.dll from the build also brings up problems with atexit()
> and _onexit(), two functions that add a deliberate layer for msvcrt.dll
> deficiencies.
> 
> Does anyone have a test that shows this problem?
> 
> I'm tinkering with making msvcr100.dll a drop-in replacement for
> msvcrt.dll (no manifest req'd), and I'd like to determine if that's
> fixed in msvcr100.dll.
> 

According to MSDN, atexit[1] and _onexit[2] are very much a part of the
2010 version of the library.

[1] http://msdn.microsoft.com/en-us/library/tze57ck3
[2] http://msdn.microsoft.com/en-us/library/zk17ww08(v=VS.100)

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] atexit() & _onexit(): crt1 & dllcrt vs msvcrt.dll

[Jim B. <Ji...@JC...>]

On 1:59 PM, Earnie wrote:
> Jim Bell wrote:
>> Removing msvcrt.dll from the build also brings up problems with atexit()
>> and _onexit(), two functions that add a deliberate layer for msvcrt.dll
>> deficiencies.
>>
>> Does anyone have a test that shows this problem?
>>
>> I'm tinkering with making msvcr100.dll a drop-in replacement for
>> msvcrt.dll (no manifest req'd), and I'd like to determine if that's
>> fixed in msvcr100.dll.
>>
> According to MSDN, atexit[1] and _onexit[2] are very much a part of the
> 2010 version of the library.
>
> [1] http://msdn.microsoft.com/en-us/library/tze57ck3
> [2] http://msdn.microsoft.com/en-us/library/zk17ww08(v=VS.100)
>

But they were very much a part of the msvcrt.dll version, too. Still,
MinGW decided it needed to wrap them.

What was the criteria for the wrap? From the comments, it appears not to
work correctly across DLL boundaries.

Re: [Mingw-users] atexit() & _onexit(): crt1 & dllcrt vs msvcrt.dll

[Earnie <ea...@us...>]

Jim Bell wrote:
> 
> But they were very much a part of the msvcrt.dll version, too. Still,
> MinGW decided it needed to wrap them.
> 

But since they'll be resolved by the msvcr100 library during the link
the ones in msvcrt will not be used.

objdump -x msvcr100.dll | less

Look for _onexit and atexit.

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] atexit() & _onexit(): crt1 & dllcrt vs msvcrt.dll

[Jim B. <Ji...@JC...>]

On 1:59 PM, Earnie wrote:
> Jim Bell wrote:
>> But they were very much a part of the msvcrt.dll version, too. Still,
>> MinGW decided it needed to wrap them.
>>
> But since they'll be resolved by the msvcr100 library during the link
> the ones in msvcrt will not be used.
>
> objdump -x msvcr100.dll | less
>
> Look for _onexit and atexit.

They're in there. The problem is, they conflict with MinGW's definitions
in dllcrt1.c and crt1.c.

>From dllcrt1.c:
/*
 * The atexit exported from msvcrt.dll causes problems in DLLs.
 * Here, we override the exported version of atexit with one that passes the
 * private table initialised in DllMainCRTStartup to __dllonexit.
 * That means we have to hide the mscvrt.dll atexit because the
 * atexit defined here gets __dllonexit from the same lib.
 */

So to adapt that comment to a question: How can we tell if the atexit
exported from msvcr100.dll causes problems in DLLs?

Re: [Mingw-users] atexit() & _onexit(): crt1 & dllcrt vs msvcrt.dll

[Earnie <ea...@us...>]

Jim Bell wrote:
> 
> 
> On 1:59 PM, Earnie wrote:
>> Jim Bell wrote:
>>> But they were very much a part of the msvcrt.dll version, too. Still,
>>> MinGW decided it needed to wrap them.
>>>
>> But since they'll be resolved by the msvcr100 library during the link
>> the ones in msvcrt will not be used.
>>
>> objdump -x msvcr100.dll | less
>>
>> Look for _onexit and atexit.
> 
> They're in there. The problem is, they conflict with MinGW's definitions
> in dllcrt1.c and crt1.c.
> 
>>From dllcrt1.c:
> /*
>  * The atexit exported from msvcrt.dll causes problems in DLLs.
>  * Here, we override the exported version of atexit with one that passes the
>  * private table initialised in DllMainCRTStartup to __dllonexit.
>  * That means we have to hide the mscvrt.dll atexit because the
>  * atexit defined here gets __dllonexit from the same lib.
>  */
> 
> So to adapt that comment to a question: How can we tell if the atexit
> exported from msvcr100.dll causes problems in DLLs?

Is __dllonexit exported in msvcr100.dll?  If so then msvcrt.dll will not
be used to resolve it.  This source file creates an object file
delivered to the lib directory and when used requires it's dependencies
be found in the provided library.  The comment just references
msvcrt.dll because that is what is standard.  You are replacing the
standard with msvcr100.dll.

-- 
Earnie
-- http://www.for-my-kids.com