Missing variable 'pe_data_import_dll'

Charles Wilson cwilson@ece.gatech.edu
Mon Sep 24 09:42:00 GMT 2001


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. :-)

Nick Clifton wrote:

> Hi Guys,
> 
>   OK, Sorry about this.  I have had to revert Charle's patch to fix
>   pe_data_import_dll' since it breaks --enable-targets=all builds.
> 
>   Instead I have just moved the definition of pe_data_import_dll
>   outside of the section of code controlled by DLL_SUPPORT, so that it
>   will be available even for targets like the arm-epoc-pe.


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?

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?
-------

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.

I'm just glad that other targets can build, now.

--Chuck

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...





More information about the Binutils mailing list