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:	<BMSMTP8586264222a0182636.cygnus.gnu-win32@dsbmail.itg.ti.com>
Reply-To:	John Cerney <j-cerney1 AT ti DOT com>
Mime-Version:	1.0
X-Mailer:	BeyondMail for Windows/Professional 2.3
Original-To:	"gnu-win32 AT cygnus DOT com" <gnu-win32 AT cygnus DOT com>,
	Sergey Okhapkin
	<sos AT prospect DOT com DOT ru>
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 <sos AT prospect DOT com DOT ru>, 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 <stdio.h> 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".

- Raw text -