On Feb 20 10:38, Christopher Faylor wrote:
> On Thu, Feb 20, 2014 at 03:57:27PM +0100, Corinna Vinschen wrote:
> >On Feb 20 14:16, Jaime Fabregas Fernandez wrote:
> >> Hello Corinna,
> >>
> >> As you've checked, this behaviour doesn't appear with dll's created by
> >> gcc, but it does with Visual
On Thu, Feb 20, 2014 at 03:57:27PM +0100, Corinna Vinschen wrote:
>On Feb 20 14:16, Jaime Fabregas Fernandez wrote:
>> Hello Corinna,
>>
>> As you've checked, this behaviour doesn't appear with dll's created by
>> gcc, but it does with Visual Studio C++.
>> That minimal example compiled with VS wi
On Feb 20 14:16, Jaime Fabregas Fernandez wrote:
> Hello Corinna,
>
> As you've checked, this behaviour doesn't appear with dll's created by
> gcc, but it does with Visual Studio C++.
> That minimal example compiled with VS will result in the freeze of the
> child process.
>
> te
Hello Corinna,
As you've checked, this behaviour doesn't appear with dll's created by
gcc, but it does with Visual Studio C++.
That minimal example compiled with VS will result in the freeze of the
child process.
testlib.h ==
#ifdef TESTLIB_EXPORTS
#define TES
On Feb 19 14:38, Jaime Fabregas Fernandez wrote:
> Library references loaded by a process using dlopen() and dlsym() are
> no more valid in child processes after running a fork(). Calls from
> child process will never return.
>
> I've searched for a similar problem in the mailing lists and found
>
Library references loaded by a process using dlopen() and dlsym() are
no more valid in child processes after running a fork(). Calls from
child process will never return.
I've searched for a similar problem in the mailing lists and found
this unanswered thread from 2001:
http://cygwin.com/ml/cygw
6 matches
Mail list logo
