This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Missing variable 'pe_data_import_dll'
- To: Nick Clifton <nickc at cambridge dot redhat dot com>
- Subject: Re: Missing variable 'pe_data_import_dll'
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- Date: Mon, 24 Sep 2001 15:20:36 -0400
- CC: binutils at sources dot redhat dot com
- References: <m3pu8g7h2a.fsf@north-pole.nickc.cambridge.redhat.com> <3BAF59FC.3070802@ece.gatech.edu> <m3pu8g5u4l.fsf@north-pole.nickc.cambridge.redhat.com>
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
>
>