Subject: RE: Can't Reference Stderr from a DLL
From: [email-masked] (John Cerney)

17 Mar 1997 10:55:12 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Reply-To: John Cerney <[email-masked]>
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: "[email-masked]" <[email-masked]>,
        Sergey Okhapkin
	<[email-masked]>
X-BeyondMail-Priority: 1
Conversation-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Receipt-From-Agent: true
Original-Sender: [email-masked]

>  From: Sergey Okhapkin <[email-masked]>, 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
"[email-masked]" with one line of text: "help".