Bugs item #3156957, was opened at 2011-01-13 07:41
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3156957&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: non-mingw
Group: Unreproducible
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Donald Douwsma (donaldd8)
Assigned to: Nobody/Anonymous (nobody)
Summary: install -s strips export tables from dll's
Initial Comment:
I've been working on a project that uses the install command when
creating its installation package. The program builds both a Linux
and a Windows version from shared soruce. Both are native builds.
Unfortunately I've found that 'install -s' causes Windows dll's to have their
export tables removed, rendering them useless. Currently I'm working
around this with a platform specific override that drops the -s for Windows
builds.
Steps to reproduce.
Open a dll with depends http://www.dependencywalker.com/
and observe that there is are exports. Run install -s to copy the
dll somewhere. Open the copied dll with depends and observe
that it has trashed the export symbols.
depends /bin/iconv.dll
install -s /bin/iconv.dll ~/
depends ~/iconv.dll
I believe this is a regression as the project I'm working on previously
used install -s without these problems.
OS is Windows XP Professional
uname -a
MINGW32_NT-5.1 DD 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
install --version
install (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.
----------------------------------------------------------------------
>Comment By: Keith Marshall (keithmarshall)
Date: 2011-01-28 16:49
Message:
> I tend to agree, however stripping the exports from a dll is
> probably not a reasonable thing to do even for third party dll's.
Of course it isn't, but this seems to be peculiar to this particular third
party DLL. The exports *aren't* stripped from our build of (a much more
up-to-date version of) this DLL. We don't know of any other DLL which is
similarly afflicted, so it appears that this dinosaur is malformed in some
way, which causes it to lose its exports table. We simply don't have the
manpower resources to waste on solving problems which exist only in
somebody else's years-out-of-date DLL.
----------------------------------------------------------------------
Comment By: Donald Douwsma (donaldd8)
Date: 2011-01-27 11:28
Message:
> So, where do we go from here?
Indeed.
>> I've discovered that this problem is specific (so far) to the iconv.dll
>> from libiconv-1.9.1.mingw.tar.bz2 from openfoundry.org.
> Which kind of suggests that the problem lies, not with the MinGW tools,
> but with this particular foreign build of libiconv. Given that it is:
>1) Based on a prehistoric version of libiconv, and
>2) Not provided, and therefore not supported, by us
I tend to agree, however stripping the exports from a dll is
probably not a reasonable thing to do even for third party dll's.
> I really don't see any reason for us to pursue it further. If you are
> unwilling, or unable, to move forward to a more recent version which we
do
> provide and support, then please take up the issue with the
openfoundry.org
> folks.
We have a work around by simply not stiripping the symbols, so closing it
makes sense.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2011-01-27 09:37
Message:
So, where do we go from here?
> I've discovered that this problem is specific (so far) to the iconv.dll
> from libiconv-1.9.1.mingw.tar.bz2 from openfoundry.org.
Which kind of suggests that the problem lies, not with the MinGW tools,
but with this particular foreign build of libiconv. Given that it is:
1) Based on a prehistoric version of libiconv, and
2) Not provided, and therefore not supported, by us
I really don't see any reason for us to pursue it further. If you are
unwilling, or unable, to move forward to a more recent version which we do
provide and support, then please take up the issue with the openfoundry.org
folks.
----------------------------------------------------------------------
Comment By: Donald Douwsma (donaldd8)
Date: 2011-01-27 07:26
Message:
I tried upgrading binutils to binutils-2.21 but this did not make any
difference for me.
I've discovered that this problem is specific (so far) to the iconv.dll
from libiconv-1.9.1.mingw.tar.bz2 from openfoundry.org.
http://www.openfoundry.org/of/projects/168/download?lang=en
I'm using the openfoundry libraries as the project I was working on was
gtk1.3 and openfoundry is the only place I've managed to find a full set of
the old gtk libraries. The bug does not present with the other dlls (gdk,
gtk, etc...) from from openfoundry that I have checked so far.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2011-01-25 09:58
Message:
Okay, you clearly are seeing a problem which is not reproduced in my
setup.
> ld --version
> GNU ld (GNU Binutils) 2.20.51.20100613
This is probably relevant, only in providing an inference that you will
have the same binutils version of strip, (which install -s will use to
perform the stripping).
> I wonder if this could be specific to Msys native builds.
By this, I guess you mean MSYS *hosted* native (Win32) builds. I doubt
very much that this is the case, because I am also unable to reproduce the
issue with a similar MSYS setup on Vista:
$ uname -a
MINGW32_NT-6.0 ... 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
$ install --version
install (GNU coreutils) 5.97
...
$ strip --version
GNU strip (GNU Binutils) 2.21
...
$ pexports
PExports 0.44 Copyright 1998, Anders Norlander
Changed 1999, Paul Sokolovsky
Changed 2008, Tor Lillqvist
...
$ mkdir foo
$ cd foo
$ cp /mingw/bin/libiconv-2.dll .
$ pexports libiconv-2.dll
LIBRARY libiconv-2.dll
EXPORTS
_libiconv_version DATA
aliases2_lookup
aliases_lookup
iconv_canonicalize
libiconv
...
locale_charset
$ mkdir tmp
$ install -s libiconv-2.dll `pwd`/tmp
$ pexports tmp/libiconv-2.dll
LIBRARY libiconv-2.dll
EXPORTS
_libiconv_version DATA
aliases2_lookup
aliases_lookup
iconv_canonicalize
libiconv
...
locale_charset
The only significant difference, (assuming Vista vs. XP isn't
significant), is my binutils version, so I guess you should upgrade to
binutils-2.21:
$ mingw-get update
$ mingw-get install binutils
should do that for you, if you have mingw-get installed, and don't have
proxy issues.
----------------------------------------------------------------------
Comment By: Donald Douwsma (donaldd8)
Date: 2011-01-24 01:14
Message:
Ideally I would be cross compiling from linux too, its on my list of things
to do.
I wonder if this could be specific to Msys native builds.
ld --version
GNU ld (GNU Binutils) 2.20.51.20100613
donaldd@... ~
$ pexports /bin/iconv.dll
LIBRARY iconv.dll
EXPORTS
_libiconv_version DATA
libiconv
libiconv_close
libiconv_open
libiconv_set_relocation_prefix
libiconvctl
libiconvlist
locale_charset
donaldd@... ~
$ install -s /bin/iconv.dll /home/donaldd/
donaldd@... ~
$ pexports /home/donaldd/iconv.dll
<no output>
donaldd@... ~
$ which install
/bin/install.exe
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2011-01-19 16:16
Message:
Some additional follow-up:
I have now downloaded dependency walker to a vista box, and using my
aforementioned mingw-get DLL, with an MSYS/MinGW installation at the same
version as yours, (assuming you also have binutils-2.21, because you didn't
say), I have repeated the sequence of operations you specify. I cannot
reproduce your issue; objdump -t says no symbols, (as expected), but both
pexports and your suggested depends tool display the exports table, without
any problem.
In the absence of any additional information from you, I see no point in
pursuing this further.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2011-01-19 15:22
Message:
Before I simply suggest that you take this upstream, to the binutils
maintainers, I'd like to get a better understanding of your perceived
issue.
First, let me state that I don't use MSW as a development platform; I
cross-compile MSW code on my Linux box. Thus, I don't use dependency
walker to examine export tables -- I *do* use the pexports tool which we
ourselves provide, but compiled as a native Linux application.
Now, as I build a DLL, (e.g. the DLL component of mingw-get), I get a
default build with all symbols in place; objdump -t confirms this, and
pexports happily dumps the exports table. Before I distribute this, I
perform a stripped install into a temporary staging directory, which I
package the distribution tarballs. Running objdump -t on the stripped
staging copy of the DLL confirms that all symbols have been removed, but
this by no means renders the DLL unusable; pexports will still happily dump
the exports table.
So, before we pursue this further, could you please run pexports, rather
than depends, to confirm that your issue really is that the export table
has been destroyed, and not simply that symbols have been removed.
FWIW, my cross-binutils are version 2.21, while the native version is
2.20.51. Both are capable of stripping MSW DLLs, (and I guess it's the
native version which is invoked by install -s, unless I force the
alternative); neither destroys the exports table in the DLL.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3156957&group_id=2435
|
