Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)

Charles Wilson cygwin@cwilson.fastmail.fm
Mon Jan 25 02:27:00 GMT 2010


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



More information about the Cygwin-apps mailing list