From: Marc V. <vai...@fa...> - 2008-09-26 12:48:48
|
Looks like my message to the mailing list didn't make it thorough the spam filter b/c I used the c word. Trying again with a word substitution :) On Thu, Sep 25, 2008 at 11:16:12PM +0100, Keith Marshall wrote: > On Thursday 25 September 2008 17:16:00 Brian Dessent wrote: > > I doubt it's alignment, but rather the fact that the MSVC app is > > using a different version of the MS runtime (such as MSVCRT80.DLL) > > whereas MinGW uses MSVCRT.DLL. If you want to be able to > > malloc/free across modules like that then they have to be managed > > by the same heap manager, i.e. the same runtime. So either hack up > > MinGW to use the same runtime as the rest of the code... > > Hack up? See http://www.mingw.org/node/25#comment-106 for details of > a way to achieve this cleanly and reversibly; just watch out for > stray white space in your specs files, as noted in another recent > thread, on this list: > http://thread.gmane.org/gmane.comp.gnu.mingw.user/27606/focus=27699 I dunno, I say just put on a prophylactic and then you can link against whomever you choose. I'll get a call from someone who wants to try out one of our SDKs but is still using MSVC 6. Who wants to maintain multiple versions of their DLLs for all different runtimes. Marc ----- End forwarded message ----- |
From: Danny S. <dan...@cl...> - 2008-09-28 22:36:46
|
Keith Marshall said" > Since mingwrt-3.14, IIRC, we have shipped import libs, and the > corresponding oldname libs, to facilitate linking with MSVCR70, > MSVCR71, MSVCR80 and MSVCR90, as alternatives to MSVCRT, (and we've > also supported the debug variants of all of these). The method of > selecting from that list of alternatives, as described in the Wiki > article, is simply the final piece of the jigsaw, to complete the > infrastructure of that multiple runtime version support. This whole msvcrt-versioning needs to be reviewsed On my XP-sp2, the system MSVCRT.DLL (C:\windows\system32\msvcrt.dll) contains *almost* all of the exports defined in mingw's msvcr71.def. Its internal version string is "7.0.2600.3085" Perhaps, as with the w32api import libs, the default import lib should contain all the symbols supported by the most recent OS, leaving the onus of guarding against too-new imports/backward-compat issues to the header file guards and the user's ability to avoid shooting self in foot. Danny "A preposition is a word which you should not end a sentence with." |
From: Roumen P. <bug...@ro...> - 2008-09-30 18:45:44
|
Danny Smith wrote: > Keith Marshall said" >> Since mingwrt-3.14, IIRC, we have shipped import libs, and the >> corresponding oldname libs, to facilitate linking with MSVCR70, >> MSVCR71, MSVCR80 and MSVCR90, as alternatives to MSVCRT, (and we've >> also supported the debug variants of all of these). The method of >> selecting from that list of alternatives, as described in the Wiki >> article, is simply the final piece of the jigsaw, to complete the >> infrastructure of that multiple runtime version support. > > This whole msvcrt-versioning needs to be reviewsed On my XP-sp2, the system MSVCRT.DLL > (C:\windows\system32\msvcrt.dll) contains *almost* all of the exports defined in mingw's > msvcr71.def. Its internal version string is "7.0.2600.3085" Perhaps, as with the w32api > import libs, the default import lib should contain all the symbols supported by the most > recent OS, leaving the onus of guarding against too-new imports/backward-compat issues to > the header file guards and the user's ability to avoid shooting self in foot. MS C-runtime is not backward/forward compatible. Perhaps mingw rt has to include more import libraries as example libmsvcrt-xp.dll.a with import symbols corresponding to 7.0 and LIBRARY msvcrt.dll. What about mingwrt package to include predefined gcc specs files for various MS C-runtime ? > > Danny > "A preposition is a word which you should not end a sentence with." Roumen P.S.: resent |
From: Roumen P. <bug...@ro...> - 2008-09-30 06:47:29
|
Danny Smith wrote: > Keith Marshall said" >> Since mingwrt-3.14, IIRC, we have shipped import libs, and the >> corresponding oldname libs, to facilitate linking with MSVCR70, >> MSVCR71, MSVCR80 and MSVCR90, as alternatives to MSVCRT, (and we've >> also supported the debug variants of all of these). The method of >> selecting from that list of alternatives, as described in the Wiki >> article, is simply the final piece of the jigsaw, to complete the >> infrastructure of that multiple runtime version support. > > This whole msvcrt-versioning needs to be reviewsed On my XP-sp2, the system MSVCRT.DLL > (C:\windows\system32\msvcrt.dll) contains *almost* all of the exports defined in mingw's > msvcr71.def. Its internal version string is "7.0.2600.3085" Perhaps, as with the w32api > import libs, the default import lib should contain all the symbols supported by the most > recent OS, leaving the onus of guarding against too-new imports/backward-compat issues to > the header file guards and the user's ability to avoid shooting self in foot. MS C-runtime is not backward compatible. Perhaps mingw rt has to include more import libraries as example libmsvcrt-xp.dll.a with import symbols corresponding to 7.0 and LIBRARY msvcrt.dll. What about mingwrt package to include predefined gcc specs files for various MS C-runtime ? > > Danny > "A preposition is a word which you should not end a sentence with." Roumen |
From: Ross B. <Ross@CheshireEng.com> - 2008-09-30 04:45:15
|
Sometime on 9/28/2008, Keith Marshall wrote: >.... >That isn't in dispute. The value of this method of selecting >alternative MSVCRT versions is realised, when you need a feature of >one of the newer versions which is not available in the default >MSVCRT used by MinGW. Or when you need trouble-free integration with an application built with, shipping, and initializing a particular flavor of the MSVC runtime. In that scenario, you may not have any choice at all given that some APIs (which I'd be the first to agree isn't the best approach) return pointers that the caller is expected to free() themselves. >Since mingwrt-3.14, IIRC, we have shipped import libs, and the >corresponding oldname libs, to facilitate linking with MSVCR70, >MSVCR71, MSVCR80 and MSVCR90, as alternatives to MSVCRT, (and we've >also supported the debug variants of all of these). The method of >selecting from that list of alternatives, as described in the Wiki >article, is simply the final piece of the jigsaw, to complete the >infrastructure of that multiple runtime version support. I would like to gently suggest that a future release of MinGW include these changes to the GCC spec files. There are at least two advantages to the MinGW community here. First, the integration of the known CRT versions DLLs would be tested, at least on some platform for each version, and could be trusted or even expected to work. Second, it would standardize the names selected for each version. As much as I want to argue that a runtime like MSVCRT.DLL is the best choice since it is a system component in many versions of Windows and hence has no installation requirements or license issues that matter, the fact is that there are many scenarios where it is necessary to pick one of the newer versions. And when faced with that need, figuring out how to make it all work right is not as easy as it could be. While wishing, the advent of Side-by-Side assemblies and the delivery of newer CRT versions as such creates a need for a tool to build the needed manifests. The existing windres tool along with ld is adequate for attaching a hand-crafted manifest. However, it would be nice to make the generation of correct manifests nearly as easy as Visual Studio makes it. Ross Berteig Ross@CheshireEng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ |
From: Danny S. <dan...@cl...> - 2008-09-30 09:58:48
|
> From: Ross Berteig > > I would like to gently suggest that a future release of MinGW > include these changes to the GCC spec files. Submit a patch. > While wishing, the advent of Side-by-Side assemblies and the > delivery of newer CRT versions as such creates a need for a tool > to build the needed manifests. The existing windres tool along > with ld is adequate for attaching a hand-crafted manifest. > However, it would be nice to make the generation of correct > manifests nearly as easy as Visual Studio makes it. Submit a patch. brg Danny |
From: Keith M. <kei...@us...> - 2008-09-27 09:36:50
|
On Friday 26 September 2008 13:48:31 Marc Vaillant wrote: > Looks like my message to the mailing list didn't make it thorough > the spam filter ... Or, maybe it got sucked into the black hole, which seems to have recently appeared in the vicinity of the SF mail servers. > > On Thu, Sep 25, 2008 at 11:16:12PM +0100, Keith Marshall wrote: > > On Thursday 25 September 2008 17:16:00 Brian Dessent wrote: > > > I doubt it's alignment, but rather the fact that the MSVC app > > > is using a different version of the MS runtime (such as > > > MSVCRT80.DLL) whereas MinGW uses MSVCRT.DLL. If you want to be > > > able to malloc/free across modules like that then they have to > > > be managed by the same heap manager, i.e. the same runtime. So > > > either hack up MinGW to use the same runtime as the rest of the > > > code... > > > > Hack up? See http://www.mingw.org/node/25#comment-106 for > > details of a way to achieve this cleanly and reversibly; just > > watch out for stray white space in your specs files, as noted in > > another recent thread, on this list: > > http://thread.gmane.org/gmane.comp.gnu.mingw.user/27606/ > >focus=27699 > > I dunno, I say just put on a prophylactic and then you can link > against whomever you choose. I'll get a call from someone who > wants to try out one of our SDKs but is still using MSVC 6. Who > wants to maintain multiple versions of their DLLs for all different > runtimes. Sure. I don't doubt that your advice offers an effective method for avoiding the OP's problem; Brian said as much too, when he advised keeping memory allocation and deallocation "on the same side of the fence". However, Brian also suggested an alternative strategy, which may or may not be as effective, depending on circumstances; he indicated that this alternative strategy would require "hacking up" MinGW. The link I posted *doesn't* address the OP's problem per se. However, it does provide a step-by-step guide, describing how to implement Brian's alternative strategy in a manner which I would submit does *not* constitute "hacking up" MinGW; it exploits a standard feature of GCC's configuration, in a formally documented manner, which MinGW has supported since the advent of GCC-3.x, at the latest, and probably even before that. Regards, Keith. |
From: Deepak C. <dch...@gm...> - 2008-09-27 16:11:35
|
Thanks for the numerous suggestions. I am trying the simpler solutions (making sure alloc/delloc pairs do not cross the fence). That was the problem in a couple of cases, but I still get one heap corruption, which I think it might just be a bug not related to the dll issue. By the way, all of these are C dlls, and I'm using gcc to do run-time compilation -and-loading -- that is why I have to mix msvc++ and mingw. I could switch over entirely to mingw, which was an option is nothing else worked. On Sat, Sep 27, 2008 at 2:36 AM, Keith Marshall <kei...@us...> wrote: > On Friday 26 September 2008 13:48:31 Marc Vaillant wrote: >> Looks like my message to the mailing list didn't make it thorough >> the spam filter ... > > Or, maybe it got sucked into the black hole, which seems to have > recently appeared in the vicinity of the SF mail servers. >> >> On Thu, Sep 25, 2008 at 11:16:12PM +0100, Keith Marshall wrote: >> > On Thursday 25 September 2008 17:16:00 Brian Dessent wrote: >> > > I doubt it's alignment, but rather the fact that the MSVC app >> > > is using a different version of the MS runtime (such as >> > > MSVCRT80.DLL) whereas MinGW uses MSVCRT.DLL. If you want to be >> > > able to malloc/free across modules like that then they have to >> > > be managed by the same heap manager, i.e. the same runtime. So >> > > either hack up MinGW to use the same runtime as the rest of the >> > > code... >> > >> > Hack up? See http://www.mingw.org/node/25#comment-106 for >> > details of a way to achieve this cleanly and reversibly; just >> > watch out for stray white space in your specs files, as noted in >> > another recent thread, on this list: >> > http://thread.gmane.org/gmane.comp.gnu.mingw.user/27606/ >> >focus=27699 >> >> I dunno, I say just put on a prophylactic and then you can link >> against whomever you choose. I'll get a call from someone who >> wants to try out one of our SDKs but is still using MSVC 6. Who >> wants to maintain multiple versions of their DLLs for all different >> runtimes. > > Sure. I don't doubt that your advice offers an effective method for > avoiding the OP's problem; Brian said as much too, when he advised > keeping memory allocation and deallocation "on the same side of the > fence". > > However, Brian also suggested an alternative strategy, which may or > may not be as effective, depending on circumstances; he indicated > that this alternative strategy would require "hacking up" MinGW. > > The link I posted *doesn't* address the OP's problem per se. However, > it does provide a step-by-step guide, describing how to implement > Brian's alternative strategy in a manner which I would submit does > *not* constitute "hacking up" MinGW; it exploits a standard feature > of GCC's configuration, in a formally documented manner, which MinGW > has supported since the advent of GCC-3.x, at the latest, and > probably even before that. > > Regards, > Keith. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Marc V. <vai...@fa...> - 2008-09-27 18:34:11
|
On Sat, Sep 27, 2008 at 10:36:26AM +0100, Keith Marshall wrote: > On Friday 26 September 2008 13:48:31 Marc Vaillant wrote: > > Looks like my message to the mailing list didn't make it thorough > > the spam filter ... > > Or, maybe it got sucked into the black hole, which seems to have > recently appeared in the vicinity of the SF mail servers. ah, ok. > > .... > > I dunno, I say just put on a prophylactic and then you can link > > against whomever you choose. I'll get a call from someone who > > wants to try out one of our SDKs but is still using MSVC 6. Who > > wants to maintain multiple versions of their DLLs for all different > > runtimes. > > Sure. I don't doubt that your advice offers an effective method for > avoiding the OP's problem; Brian said as much too, when he advised > keeping memory allocation and deallocation "on the same side of the > fence". Yes, I was just putting in my vote for that approach. > > However, Brian also suggested an alternative strategy, which may or > may not be as effective, depending on circumstances; he indicated > that this alternative strategy would require "hacking up" MinGW. > > The link I posted *doesn't* address the OP's problem per se. However, > it does provide a step-by-step guide, describing how to implement > Brian's alternative strategy in a manner which I would submit does > *not* constitute "hacking up" MinGW; it exploits a standard feature > of GCC's configuration, in a formally documented manner, which MinGW > has supported since the advent of GCC-3.x, at the latest, and > probably even before that. I'm really not claiming that it's a useless feature. It's just that in the case where you are--or might be--distributing DLLS, they will be far more flexible if you don't require a particular runtime. It's even an annoyance when staying withing the same version of MSVC. You may like to use the debug runtime, say for your main program, without having to recompile all your DLLs to use that runtime. Marc |
From: Keith M. <kei...@us...> - 2008-09-28 07:37:12
|
On Saturday 27 September 2008 19:34:02 Marc Vaillant wrote: > > The link I posted *doesn't* address the OP's problem per se. > > However, it does provide a step-by-step guide, describing how to > > implement Brian's alternative strategy in a manner which I would > > submit does *not* constitute "hacking up" MinGW; it exploits a > > standard feature of GCC's configuration, in a formally documented > > manner, which MinGW has supported since the advent of GCC-3.x, at > > the latest, and probably even before that. > > I'm really not claiming that it's a useless feature. It's just > that in the case where you are--or might be--distributing DLLS, > they will be far more flexible if you don't require a particular > runtime. That isn't in dispute. The value of this method of selecting alternative MSVCRT versions is realised, when you need a feature of one of the newer versions which is not available in the default MSVCRT used by MinGW. Since mingwrt-3.14, IIRC, we have shipped import libs, and the corresponding oldname libs, to facilitate linking with MSVCR70, MSVCR71, MSVCR80 and MSVCR90, as alternatives to MSVCRT, (and we've also supported the debug variants of all of these). The method of selecting from that list of alternatives, as described in the Wiki article, is simply the final piece of the jigsaw, to complete the infrastructure of that multiple runtime version support. As I hinted, it's rather more generalised in intent, than specific to the OP's issue. Regards, Keith. |