Install/stage on Windows with GCC doesn't copy DLLs.

[René Rivera]

Doing a install/stage at the boost-root with either gcc-mingw, of gcc-cygwin fails to copy the DLLs for the built libraries. This is because the gcc-linking-generator in tools/gcc.jam strips out the DLL target which the install needs to tell when a DLL is created. Dave Abrahams explains that strip choice as:

# If more than one target was generated, throw out the
# last one, which on windows just leaves the import
# library.  Most generators on windows simply don't accept
# shared libraries as input, but being able to link
# directly to a shared library without an import library
# is an important capability of GCC.  Therefore, we remove
# the target after the action sees it so that dependent
# targets don't try to link to both the import library and
# the DLL.

I'm not sure which situation Dave has in mind but I changed the code to not throw out the DLL targets and tested building a variety of libraries, including the embeded Python example, and AFAICT both MinGW and Cygwin both deal fine with the DLL and import libs just fine. I attach a patch that reverts this one change. It was tested with gcc-mingw-3.4.5, gcc-cygwin-3.4.4, and msvc-8.0.

We need Dave's go ahead for this one since he knows the context of the breaking change.

[René Rivera]

Verified that the patch works for both MinGW and Cygwin compilers, both in their respective Bash shells, and from the Windows CMD shell.

[René Rivera]

Additional fix the bring back Dave's functionality. But in the same form as for all the other Windows toolsets.

[René Rivera]

My original "fix" created some regressions. It turns out the functionality Dave was working around with the original logic was to remove duplicate symbols when linking on some circumstances. The new patch fixes it in the same way all the other Windows toolsets, like msvc.jam and borland.jam, define the linking generators.

[René Rivera]

Thomas,

Since you seem to be otherwise occupied, and we really need to get this tested, I checked this in. I had already tested it on Linux (gcc-4.1.2 and gcc-4.2.0), MinGW (gcc-3.4.5), and Cygwin (gcc-3.4.4). But the regression tools fail to process my Cygwin logs because I did the test inside the cygwin shell.

[pass86@…]

Oh, it is a bug original.I finding the reason now.Now I find it.