[PATCH] pei386, ld auto-import

Charles Wilson cwilson@ece.gatech.edu
Sun Sep 23 14:51:00 GMT 2001


In this message:

Missing variable 'pe_data_import_dll'
http://sources.redhat.com/ml/binutils/2001-08/msg00186.html

Nick Clifton reported that the recently accepted auto-import changes to 
ld on pei386 caused a build problem on other pe platforms that don't 
support DLLs (specifically arm-epoc-pe).

This was because the auto-import changes added a reference in pe-dll.c 
to a variable in pe.em -- but that variable wasn't defined unless 
DLL_SUPPORT was defined.

Now, Nick posted a workaround to the problem here:
http://sources.redhat.com/ml/binutils/2001-08/msg00187.html
but AFAICT it was never applied to CVS.  (Plus, it was just a 
workaround).  In that message, Nick also suggested the following:

   I still
   feel however, that there ought to be a better way to solve this
   problem.  My suggestion is that the definition of DLL_SUPPORT ought
   to be set in ld/configure.tgt rather than ld/emultemp/pe.em and then
   tested in ld/pe-dll.c before it uses variables that are only defined
   in pe.em.

That's not what I did, because ld/configure.tgt seems to only set shell 
variables, which are later used to control Makefile options.  However, 
the list of acceptable shell variables is fixed: targ_emul, 
targ_extra_emuls, targ_extra_libpath, and targ_extra_ofiles.  These are 
then (eventually) used by configure to fixup the Makefile.in's when 
generating the Makefile's.  So, sure, it's *possible* to do what Nick 
suggests -- by changing configure.in/configure so that it will replace 
@DLL_SUPPORT@, adding a few more rules to Makefile.in, adding 
DLL_SUPPORT where appropriate in configure.tgt, etc., but ...

It really doesn't seem right to me that "DLL_SUPPORT" be added to the 
list of stuff controlled by configure.tgt, which is currently limited to 
things like targ_*.  Comments?

So, the attached patch is identical to the one I posted a few days ago, 
but the Subject line of that earlier message was probably misleading. 
Anyway, the attached patch fixes this problem by:
  a) make the offending variable (pe_data_import_dll) static within pe.em
  b) add a new function in pe.em (pe_get_data_import_dll_name) which 
either returns this variable (#ifdef DLL_SUPPORT), or returns a constant 
  string (#else).  However, at least the function itself is always defined.

Could somebody on arm-epoc-pe or other non-DLL-supporting pe platform 
please verify that this patch allows successful compilation/operation of 
binutils?  the patched version does work on cygwin (but the unpatched 
version worked on cygwin, too)

Thanks,
Chuck


More information about the Binutils mailing list