Yaakov (Cygwin/X) wrote: > On 24/01/2010 19:03, JonY wrote: >> There are also some issues for DLL'ized GCC target libs, such as >> libstdc++-6.dll. I've decided they should be disabled for mingw and >> mingw-w64 based 4.x toolchains for the moment, as they all wanted to be >> installed as libstdc++-6.dll into bindir, causing potential confusion >> for users. It can be re-enabled after its fixed in upstream GCC and >> libtool. > > Whatever you do, the cross-compilers need to match what the target's > native compiler would do. So if mingw's own toolchains are shipping and > using shared GCC libraries, AFAICS you should do the same by enabling > shared libraries and shipping the *import* libs but NOT the DLLs (which > you only need to *execute* programs, which you're not doing because this > is a *cross*-compile situation).
There's no conflict between the cygwin libraries and the mingw ones; the gcc devs took care that the cygwin DLLs used the 'cyg*dll' pattern. Now, the conflict between the 32bit and 64bit DLLs? IMO, that would have been a show-stopper before rolling out the 64bit compiler in the first place: First, Do No Harm. Surely is was self-evidently obvious that people would want to run/install both 64bit and 32bit apps on the same system? But no care was taken to prevent this conflict. Sigh. However, given that a /real/ solution to this problem is not likely to come soon, I'd probably just install the runtime DLLs into the /usr/$triple/bin area -- since the $triples are different -- and let the end-user copy whichever one she wants into /usr/bin manually. -- Chuck
