This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Missing variable 'pe_data_import_dll'


This is a message sent by Nick, but because I had previously mistyped 
the binutils mailing list address, Nick's Reply-to-all went only to me 
(and the ether).  I'm replying it back to the list for archival purposes.

Nick Clifton wrote:

> Hi Charles,
> 
> 
>>First, thanks for testing.  I had hoped my "solution" would solve this
>>problem for all targets but if not then it should be discarded -- as
>>you have done. :-)
>>
> 
> Of course you could always do these tests yourself.  It does not take
> very long to configure and build and arm-epoc-pe target and an
> --enable-targets=all target.  You do not have to be able to execute
> any of the code these targets will generate.  Just having them build
> is a very good initial test.
> 
> 
>>Since you had to move pe_data_import_dll outside the DLL_SUPPORT
>>code to get --enable-targets=all to work, then the targ_cflags idea
>>for controlling DLL_SUPPORT won't really fix that, right?
>>
> 
> Well it is no longer necessary, correct.
>  
> 
>>Your explanation of the configure.tgt/targ_cflags idea was what I
>>thought you meant.  However, targ_cflags is orthogonal to the
>>pe_data_import_dll "problem" now that pe_data_import_dll is outside
>>#ifdef DLL_SUPPORT.  I can still pursue the "define DLL_SUPPORT from
>>configure.tgt" idea, via targ_cflags, configure, Makefile.in, etc,
>>tho, if you like.
>>
>>Should I?
>>
> 
> No - we have a fix that is simple and works.  There is no need to
> complicate things further.
> 
> 
>>Other than the fact that sharing a veriable between pe.em and
>>pe-dll.c offends my sense of aesthetics, I think your solution is a
>>good one. Further, given the multiple-pe-target situation, I think
>>your solution is the cleanest solution we can hope for, without
>>adding another gld_${EMULATION_NAME}_* function -- which is a far
>>more intrusive change than we want.
>>
> 
> Exactly.
> 
> 
>>P.S. How long does it normally take for checkins to propogate to
>>anoncvs@sources.redhat.com:/cvs/src (is sources. a CVSup mirror)?
>>I've tried to update but I'm not getting your changes yet...
>>
> 
> Oops - that is because I comitted the ChangeLog and not the files!
> Doh!  I have now committed the changes.  Sorry.
> 
> Cheers
>         Nick
> 
> 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]