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