This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] pei386, ld auto-import
Nick Clifton wrote:
> As you have probably guessed this version of the patch is unsuitable
> too. There are two problems:
> 1. The new function pe_get_data_import_dll_name() is defined inside
> #ifdef DLL_SUPPORT code, and so is not present for targets like
> arm-epoc-pe. (This of course is easily fixed).
Oops. I intended for it to be outside of DLL_SUPPORT. However, that's
a moot point, given:
> 2. The new function pe_get_data_import_dll_name() is a global
> function and will be multiply defined if ld is configured for
> more than one PE target. eg when building ld with
> --enable-targets=all specified. This is much harder to fix.
Ah. So having an unitialized variable for non-DLL_SUPPORT targets is
good; within the DLL_SUPPORT code path it becomes initialized. Then in
pe-dll.c, test for initialization. Something you can do with vars that
you can't easily do with functions.
> I have applied a workaround instead - of moving the definition of the
> pe_data_import_dll variable outside of the #ifdef DLL_SUPPORT
> controlled code - however if you feel that this is unsuitable then
> please feel free to submit a different solution.
No, your version seems fine to me. As long as there is a *reason* to
share a variable between two files, and that variable is defined for all
environments (e.g. no build breakages) then I'm happy. Here, using a
variable allows you to do things that aren't easily possible with
"accessor" functions, like my patch tried to do.
Discussion continued on other thread.