Here are the other two patches, recently submitted to binutils@. --Chuck
2001-09-21 Charles Wilson <[EMAIL PROTECTED]> * emultempl/pe.em(pe_data_import_dll): Make static. (pe_get_data_import_dll_name): New accessor function. * pe-dll.c(pe_create_import_fixup): call pe_get_data_import_dll_name() from pe.em, instead of directly accessing pe_data_import_dll variable from pe.em.
2001-09-21 Charles Wilson <[EMAIL PROTECTED]> * ld.texinfo(enable-auto-import): clarify the explanation.
Index: ld/pe-dll.c =================================================================== RCS file: /cvs/src/src/ld/pe-dll.c,v retrieving revision 1.30 diff -u -r1.30 old/ld/pe-dll.c new/ld/pe-dll.c --- old/ld/pe-dll.c 2001/09/19 05:33:33 1.30 +++ new/ld/pe-dll.c 2001/09/21 06:09:49 @@ -123,6 +123,9 @@ static void add_bfd_to_link PARAMS ((bfd *, const char *, struct bfd_link_info *)); +extern char * +pe_get_data_import_dll_name PARAMS(( )); /* Defined in emultempl/pe.em. */ + /* For emultempl/pe.em. */ def_file * pe_def_file = 0; @@ -2065,10 +2068,9 @@ } { - extern char * pe_data_import_dll; /* Defined in emultempl/pe.em. */ - - bfd *b = make_import_fixup_entry (name, fixup_name, pe_data_import_dll, - output_bfd); + bfd *b = make_import_fixup_entry (name, fixup_name, + pe_get_data_import_dll_name(), + output_bfd); add_bfd_to_link (b, b->filename, &link_info); } } Index: ld/emultempl/pe.em =================================================================== RCS file: /cvs/src/src/ld/emultempl/pe.em,v retrieving revision 1.52 diff -u -r1.52 old/ld/emultempl/pe.em new/ld/emultempl/pe.em --- old/ld/emultempl/pe.em 2001/09/18 10:10:21 1.52 +++ new/ld/emultempl/pe.em 2001/09/21 06:09:51 @@ -153,6 +153,7 @@ static char *pe_implib_filename = NULL; static int pe_enable_auto_image_base = 0; static char *pe_dll_search_prefix = NULL; +static char *pe_data_import_dll = NULL; #endif extern const char *output_filename; @@ -879,7 +880,32 @@ return 1; } -char *pe_data_import_dll; +/* Previously, pe-dll.c directly accessed pe_data_import_dll, + * which was only defined if DLL_SUPPORT. This cause a build + * failure on certain targets. At least this function will + * exist regardless of whether DLL_SUPPORT is defined or not. + * + * However, it's still a kludge. pe-dll.c shouldn't directly + * call any functions other than the gld_${EMULATION_NAME}_* + * Nick suggests the following method: + * 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. + * However, I don't understand this. ld/configure.tgt sets SHELL + * variables, not #define variables. You'd need #define variables + * to #ifdef out the offending sections of code from pe-dll.c + */ +char * +pe_get_data_import_dll_name () +{ +#ifdef DLL_SUPPORT + return pe_data_import_dll; +#else + return "unknown"; +#endif +} static void pe_find_data_imports ()
Index: ld.texinfo =================================================================== RCS file: /cvs/src/src/ld/ld.texinfo,v retrieving revision 1.49 diff -u -r1.49 ld.texinfo --- ld.texinfo 2001/09/12 15:58:10 1.49 +++ ld.texinfo 2001/09/21 06:42:08 @@ -1738,9 +1738,15 @@ ultimately given by the sum of two constants (Win32 import tables only allow one). Instances where this may occur include accesses to member fields of struct variables imported from a DLL, as well as using a -constant index into an array variable imported from a DLL. There are -several ways to address this difficulty. +constant index into an array variable imported from a DLL. Any +multiword variable (arrays, structs, long long, etc) may trigger +this error condition. However, regardless of the exact data type +of the offending exported variable, ld will always detect it, issue +the warning, and exit. +There are several ways to address this difficulty, regardless of the +data type of the exported variable: + One solution is to force one of the 'constants' to be a variable -- that is, unknown and un-optimizable at compile time. For arrays, there are two possibilities: a) make the indexee (the array's address) @@ -1760,12 +1766,19 @@ @{ volatile int t=1; extern_array[t] @} @end example -For structs, the only option is to make the struct itself variable: +For structs (and most other multiword data types) the only option +is to make the struct (or long long, or ...) itself variable: @example extern struct s extern_struct; extern_struct.field --> @{ volatile struct s *t=&extern_struct; t->field @} +@end example + +@example +extern long long extern_ll; +extern_ll --> + @{ volatile long long * local_ll=&extern_ll; *local_ll=... @} @end example A second method of dealing with this difficulty is to abandon