From: j-cerney1 AT ti DOT com (John Cerney) Subject: RE: Can't Reference Stderr from a DLL 17 Mar 1997 10:55:12 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: Reply-To: John Cerney Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Mailer: BeyondMail for Windows/Professional 2.3 Original-To: "gnu-win32 AT cygnus DOT com" , Sergey Okhapkin X-BeyondMail-Priority: 1 Conversation-ID: <01BC2FA2 DOT 414464E0 AT gater DOT krystalbank DOT msk DOT ru> In-Reply-To: <01BC2FA2.414464E0@gater.krystalbank.msk.ru> X-Receipt-From-Agent: true Original-Sender: owner-gnu-win32 AT cygnus DOT com > From: Sergey Okhapkin , on 3/13/97 11:32 AM: > John Cerney wrote: > > I've run into problem trying to build a dynamic lib version of > perl5.003_25. > > > > Looking at the cygwin.dll source code, it appears that stderr is > translated to > > _impure_ptr->stderr by the defines inside of the include. > _impure_ptr > > is defined in libccrt0.cc inside of cygwin.dll, which also references > main(). > > Does the linker try to resolve all references in an object file, even if > you > > just refer to one variable that is defined in it? > > > > I have tried building the DLL using the --noinhibit-exec linker option. > The dll > > is built in this case, but the main.exe executable crashes with a seg > fault. > > > > This is due to _impure_ptr in a main program and in DLL are _different_ > variables! And _impure_ptr in a DLL is not initialised to point to > reent_data structure in a main program. I have the same troubles with X > libraries builded as DLL. I already wrote mr. Noer about this bug, no > answer for a now... > > -- > Sergey Okhapkin > Moscow, Russia > Looking for a job. > > Thanks for the input on the problem. I ended up puting in a impure_ptr initialization routine that is called by my main program before it uses any functions in a DLL. Now I have another problem: Have you had any luck exporting global data variables from/to a DLL? Dlltool seems to treat all exports as function names. i.e. they show up as 'T _VariableName' when you do a 'nm libname.a', where libname.a is the import lib generated by dlltool. If you do a 'nm libname.o' (libname.o is the object code for the dll) the global variable shows up properly as 'D _VariableName'. Thanks, John - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".