Menu
▾
▴
[MinGW-notify] [ mingw-Bugs-3156957 ] install -s strips export tables from dll's
|
From: SF/projects/mingw n. l. <min...@li...> - 2011-01-27 09:37:35
|
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-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@dd ~ $ 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@dd ~ $ install -s /bin/iconv.dll /home/donaldd/ donaldd@dd ~ $ pexports /home/donaldd/iconv.dll <no output> donaldd@dd ~ $ 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 |