This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Strip path components from internal dll name


On Sat, Jan 15, 2005 at 11:06:49PM +1300, Danny Smith wrote:
>Hello,
>
>Using a path-qualified filename as the internal dll name in the
>.idata{6|7} section of the tail onject of a dll import lib can cause
>problems when freeing the library handle if the dll loads another dll
>using a LoadLibrary() call. A somewhat complicated example of this is
>given in the testcase accompanying this bug report to mingw:
>
>https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1047100&group_id=2435
>
>I don't know if putting a path-qualified name in the .edata section could also
>cause problems, but I have never seen a MS-linker built dll with such an internal name.  
>
>The MS utilities avoid the import lib problem by disallowing pathnames
>as a NAME or LIBRARY arg in a .def file. For example, with this def file
>
>LIBRARY "c:/foo.dll"
>EXPORTS
>  foo
>
>the comamnd 
>lib /MACHINE:IX86 /DEF:foo.def
>
>results in following:
>foo.def : warning LNK4093: Drive/Directory component ignored in "LIBRARY" statement
>   Creating library foo.lib and object foo.exp
>
>The following patch does same for ld and dlltool.
>
>When building a dll with ld --shared, the name of the image is
>only specified in a def file, otherwise it is inferred from the basename of
>the output dll or exe.  So there is only one place to warn the user
>about stripping path components.  With dlltool, there are three places where
>we could set dll_name:  with --dllname command line switch, with a def
>file specification, or by inference from the name of an output .exp
>file.  I have used lbasename in each of these three places separately,
>to allow differentiation of warning messages.  Some of the common code
>could be factored out a bit more.
>
>While doing this I noticed that the variable d_name is assigned a value
>but never actually used for anything, so I have removed it.

This is ok (was defilep.y included twice in your patch, btw?) but I've
never really liked the duplication of code between ld and dlltool,
either.  Someday it would be nice to merge all of the common code.

Musings aside, this is ok to check in.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]