[Mingw-notify] [ mingw-Bugs-1047100 ] path for dllname in dllwrap can cause corruption

[SourceForge.net <no...@so...>]

Bugs item #1047100, was opened at 2004-10-15 04:09
Message generated for change (Comment added) made by dannysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1047100&group_id=2435

Category: binutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jasper Taylor (jaspert)
Assigned to: Danny Smith (dannysmith)
Summary: path for dllname in dllwrap can cause corruption

Initial Comment:
When using the dllwrap tool, if a path other than the
working directory is given for the --dllname argument
then another dll which uses it as a library may be
corrupted.  Currently I find that it crashes when the
library dll calls FreeLibrary() to unload a dll, and
only if the calling dll has itself been loaded with
LoadLibrary().

In the example files which I include, we have:
action.c a module that prints something
dllfct.c a library that loads action.dll with LoadLibrary()
babyshim.c a module that uses the above as a library
babytcl.c which makes a .exe that loads babyshim.dll
with LoadLibrary()
dllfct.h as per dll example on web site.
recipe.bat compiles and dllwraps all the modules and
includes comments marking the versions that do and do
not work.

tst.dll is placed in a bin directory in the search path
so it can be found at run time. If it is initiallly
placed in this directory (i.e., the directory is
included in the argument of --dllname) the crash
happens when action.dll is unloaded. If it is placed in
the source directory and then moved to the bin
directory, everything works properly. Note that dllwrap
must be done again on the calling module (babyshim.o)
after building tst.dll the correct way before the whole
thing works. This leads me to suspect that the problem
is to do with libtstdll.a

OK what else do you need to know?
OS: WinXP
gcc version: 3.2.3 and 3.4.2
binutils and ld version 2.13.90 and 2.15.91 (I started
with mingw 3.1.0-1.exe out of the box then upgraded to
gcc 3.2.4 and binutils 2.15.91 with no change in the
behaviour)
Build environment: Windows command prompt

This is the smallest test case I can make that
demonstrates the problem.


----------------------------------------------------------------------

>Comment By: Danny Smith (dannysmith)
Date: 2004-10-15 17:11

Message:
Logged In: YES 
user_id=11494

Your right, the problem is in the import lib.  Modifying dlltool 
so that it strips the full path to the basename fixes the 
problem.

Hardcoding dll paths into an import lib is not supported, so I 
guess the best we can do is warn about it, strip to basenmae 
and carry on.

Danny

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1047100&group_id=2435