On Wed, 01 Jul 2009 18:55 +0200, "Ralf Wildenhues" wrote: > * Peter Rosin wrote on Wed, Jul 01, 2009 at 09:05:53AM CEST: > > >On Tue, 30 Jun 2009 16:23 +0200, "Ralf Wildenhues" wrote: > > >>Why does gcc but not msvc need them? > > > cl.exe will generate the manifest file all by itself, regardless of > > executable name. My gripe was that any file created by libtool will > > overwrite the file generated by cl.exe and I think cl.exe will do > > a better job of creating the manifest. My msvc patches then has code > > to embed the manifest into the executable using mt (manifest tool), > > but that is immaterial to this discussion. > > Have you guys considered adding manifest file functionality to GCC?
I haven't. Frankly, I'd rather see 4.x stabilize on cygwin with the current feature set, than try to add new ones right now. The reason cl.exe has the manifest functionality built in, is because as of VS2005, the runtime library (be it msvcrt80.dll, or msvcrp80.dll, or whatever) is NOT identified, located, and loaded based on its name and the path search rules we all know and love. Instead, a manifest resource is used to determine EXACTLY which patch-level version of the non-interoperable versions of msvcrt80.dll is required by the application (as identified by a GUID in the resource). You can have many different versions installed in "SxS" (side by side) directories under C:\Windows\, and none of them need (or should) be in your PATH. This is Microsoft's "solution" to DLL hell. [no comment...] For gcc, we don't *NEED* manifests for every single pe[i]-i386 image. We only "need" them for a small selection of unluckily-named exes, and then only when they are executed on Vista or above. -- Chuck
