From: SourceForge.net <no...@so...> - 2006-09-02 09:13:56
|
Bugs item #1401442, was opened at 2006-01-11 00:27 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1401442&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ld Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Brian Ripley (ripleybd) Assigned to: Danny Smith (dannysmith) Summary: Linking to a DLL does not work on NT4 Initial Comment: Linking directly to a DLL, e.g. gcc -o test.exe test.o R.dll links to R (and not R.dll, as it would with an import library). This works on Windows 2000 and XP, but not on NT4. Here is a patch for binutils/ld that solves the problem. You can check it works by using pedump to see what test.exe imports from: the name will change from R to R.dll --- pe-dll.c.keep 2005-08-27 09:31:01.000000000 +0100 +++ pe-dll.c 2006-01-10 11:14:06.000000000 +0000 @@ -2477,7 +2477,7 @@ unsigned char *expdata; char *erva; unsigned long name_rvas, ordinals, nexp, ordbase; - const char *dll_name; + char dll_name[262]; /* cannot be longer than a path */ /* Initialization with start > end guarantees that is_data will not be set by mistake, and avoids compiler warning. */ unsigned long data_start = 1; @@ -2597,8 +2597,10 @@ exp_funcbase = pe_as32 (expdata + 28); /* Use internal dll name instead of filename - to enable symbolic dll linking. */ - dll_name = erva + pe_as32 (expdata + 12); + to enable symbolic dll linking. + However, NT4 requires the .dll extension */ + strcpy(dll_name, erva + pe_as32 (expdata + 12)); + strcat(dll_name, ".dll"); /* Check to see if the dll has already been added to the definition list and if so return without error. ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2006-09-02 21:13 Message: Logged In: YES user_id=11494 Please check with latest binutils to see if problem persists. This 2006-02-01 Danny Smith <dan...@us...> * deffilep.y (def_image_name): If the image name does not have a suffix, append the default. * ld.texinfo: Document NAME, LIBRARY usage in PE- COFF .def files. should have fixed. Danny ---------------------------------------------------------------------- Comment By: Brian Ripley (ripleybd) Date: 2006-02-06 23:54 Message: Logged In: YES user_id=1423770 I did not make these DLLs. However, I found out how they were made and both the DLLs and the import libraries had a .def file which named the LIBRARY without .dll. Surely they should work in the same way? Specifically the code used was %.dll: @$(ECHO) LIBRARY $* > $*.def @$(ECHO) EXPORTS >> $*.def @$(NM) $^ > Defs @$(SED) -n '/^........ [BCDRT] _/s/^........ [BCDRT] _/ /p' Defs >> $*.def @$(RM) Defs $(DLL) --shared $(DLLFLAGS) $($*-DLLFLAGS) -o $@ $*.def $^ $($*-DLLLIBS) $(DLLLIBS) lib%.a: %.def @$(ECHO) -------- Building $@ from $^ -------- $(DLLTOOL) $(DLLTOOLFLAGS) $($*-DLLTOOLFLAGS) --dllname $*.dll --def $*.def --output-lib lib$*.a where DLL=gcc or g++ unless cross-compiling. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-02-01 08:26 Message: Logged In: YES user_id=11494 Could you please report how you build DLL's with mingw. I can only reproduce this statement: "all mingw-generated DLLs are reported without .dll" if I use a def file and do _not_ add an explicit ".dll" suffix to the LIBRARY staTement. That, I think, is where the bug is. Danny ---------------------------------------------------------------------- Comment By: Brian Ripley (ripleybd) Date: 2006-01-11 06:08 Message: Logged In: YES user_id=1423770 Further checking shows that while all mingw-generated DLLs are reported without .dll, this is not true of some others. So the addition of ".dll" needs to be conditional. I've put the patch I am using at http://www.stats.ox.ac.uk/pub/Rtools/sources-cross5/ld.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1401442&group_id=2435 |