Now the MFC has lots of:
<somefoo.cpp>
void CleanFoo() { }
int init = atexit( CleanFoo ) ;
</somefoo.cpp>
The call to atexit will in-turn call _lock if we look at _lock.c :
<lock.c> ... /* If the lock doesn't exist yet, create it */ if( lock_table[ locknum ].bInit == FALSE ) { /* Lock while we're changing the lock table */ _lock( _LOCKTAB_LOCK ); .... </lock.c>
Since we are calling on library initialization, (global variable) it might happen that the call is made before the initialization of the _LOCKTAB_LOCK (before a call to lock.c::msvcrt_init_mt_locks) and therefor I get an endless recursion.
Now this is why we have the -wrap option with the delayed load of winelib apps.
[Q}Should I submit a patch to protect that endless recursion in msvcrt. or should it be noted that all DLL s used by the winelib-application should be also linked to the wrapper (to have a chance to initialize) and submit a patch to winemaker?
P.S
Some similar problem occurs with native msvcrt.dll. That one is hard to pinpoint exactly. In any way making the wrapper link to msvcrt will solve the problem in both cases.
Free Life Boaz