From: Roger P. <rog...@gm...> - 2009-11-21 01:51:23
|
Sorry if this is a well known problem... With the following code: #include <io.h> #include <stdio.h> int main(char **args) { int x; for(x = 0; x < 10000000; x++) { int n = dup(1); // this appears to hang //printf("%d\n ", n); } } The first 2048 calls to dup return a valid descriptor, the next returns -1 (which is expected since the call failed), however the next call to dup hangs the process. Not so for gcc on linux. Anybody have any idea what is going on here? Is this expected? If a bug where should I report it? Note: there also appears to it appears to be bugs with dup2 -- hangs on the second dup2 in dup2(fd,fd),dup2(fd,fd+1) etc. http://osdir.com/ml/bug-gnulib-gnu/2009-07/msg00079.html Thanks. -r |
From: Roger P. <rog...@gm...> - 2009-11-21 02:25:19
|
> The first 2048 calls to dup return a valid descriptor, the next > returns -1 (which is expected since the call failed), however the next > call to dup hangs the process. Not so for gcc on linux. Appears from http://redmine.ruby-lang.org/issues/show/373 that msvcrt 7.1 does not display this. Not wishing to cause waves, perhaps mingw should link by default to a newer version? :) Thanks. -r |
From: Keith M. <kei...@us...> - 2009-11-21 09:16:27
|
On Saturday 21 November 2009 02:25:07 Roger Pack wrote: > Not wishing to cause waves, perhaps mingw should link by default > to a newer version? :) What; you mean explicitly to msvcr71.dll, or some later version? Sorry, but no can do. The default has to be whatever the OS provides; we aren't permitted to redistribute an appropriate version to satisfy any other introduced dependency. If you need a later version, it has to be your choice to provide it, and arrange for its deployment. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2009-11-24 15:12:21
|
Quoting Roger Pack <rog...@gm...>: > > Not wishing to cause waves, perhaps mingw should link by default to a > newer version? :) > Thanks. NO! The developer needs to supply thought when building the package. We don't allow n00bs not to think about what he needs because it might hurt more otherwise. I.E. supplying a different default could cause the supplied binary not to function because the DLL doesn't exist on every computer like msvcrt.dll does. -- Earnie |
From: Tor L. <tm...@ik...> - 2009-11-21 10:42:44
|
> The first 2048 calls to dup return a valid descriptor, the next > returns -1 (which is expected since the call failed), however the next > call to dup hangs the process. Not so for gcc on linux. Comparing to gcc on Linux is mostly pointless, as the only thing in common between MinGW and gcc on Linux is gcc, and gcc is not involved any more when you are already running the program. MinGW does not attempt to minic Linux any more than it attempts to mimic any other Unix OS. Gcc is available for most of them. What you should compare to is how the code behaves when compiled with Microsoft Visual C version 6 (because then it uses the same C runtime, msvcrt.dll, as when compiled with MinGW), and it indeed behaves the same way, hangs after around 2048 calls to dup(). That is on XP, though. On Windows 7 it works as it should (both when compiled with MinGW and MSVC6). Dunno about Vista. > Is this expected? If a bug where should I report it? To Microsoft? As it seems to be fixed in the msvcrt.dll in Windows 7 (and maybe Vista already) they appear to be aware of the problem, so I guess you could ask them to backport the fix to msvcrt.dll in XP and provide a patch. Good luck! (They might of course have a non-public patch for this available on request only, so if you (or more likely, your employer) have a suitable support contract in place, please do ask about it.) As far as I can see, MinGW is not really able to fix or work around this in their code (to the extent some such code is used at run-time) as it has no access to the internal data structures of msvcrt.dll. --tml |
From: Roger P. <rog...@gm...> - 2009-11-23 20:51:45
|
On Sat, Nov 21, 2009 at 3:42 AM, Tor Lillqvist <tm...@ik...> wrote: >> The first 2048 calls to dup return a valid descriptor, the next >> returns -1 (which is expected since the call failed), however the next >> call to dup hangs the process. Not so for gcc on linux. > > Comparing to gcc on Linux is mostly pointless, as the only thing in > common between MinGW and gcc on Linux is gcc, and gcc is not involved > any more when you are already running the program. I also compared it to MSVC 2008 express--it works there "as linux does" -- presumably because of the updated msvcrt dll, or maybe, as you pointed out, an XP bug [?] >> Is this expected? If a bug where should I report it? > > To Microsoft? Good one LOL. Any microsoft employeers listening in here? > As far as I can see, MinGW is not really able to fix or work around > this in their code (to the extent some such code is used at run-time) > as it has no access to the internal data structures of msvcrt.dll. It does make sense that there's nothing that can be done, except perhaps linking to a newer version of msvcrt.dll. Keith Marshall wrote > > What; you mean explicitly to msvcr71.dll, or some later version? > Sorry, but no can do. ... we aren't permitted to redistribute an appropriate version So, let me make sure I understand. It links by default to msvcrt.dll because that's the one developer's have on their machines, by default, however, we as developers *can* link against a different version and/or distribute our released binaries with that version, if desired? Follow up: http://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application provides some food for thought... Is there an option to static link using mingw's gcc? Also sobering is "the CRT DLL is no longer considered a system file" from http://support.microsoft.com/kb/326922 Does this mean depending on msvcrt.dll is unstable? Much thanks. -r |
From: Tor L. <tm...@ik...> - 2009-11-23 21:43:21
|
> I also compared it to MSVC 2008 express--it works there "as linux > does" Well, MSVC 2008 -compiled code does not use msvcrt.dll. It uses msvcr90.dll. The problem is in msvcrt.dll on XP at least. msvcrt.dll and msvcr90.dll are separate files, it's not like msvcr90.dll would replace msvcrt.dll completely. (To make things more confusing, the import library for the MSVC version-specific msvcr[789]*.dll DLL in is called msvcrt.lib in each MSVC version (.NET 2003, 2005 and 2008).) > we as developers *can* link against a different version > and/or distribute our released binaries with that version, if desired? It's not only a question of linking as far as I know. Except in some very trivial cases, code must be compiled against header that match the C runtime against which it will be linked. > http://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application > provides some food for thought... Note that some of the comments there are rather loosely written. Like "You must ship msvcrt with your application. It is not a guaranteed part of the operating system." which when it says "msvcrt" refers to some of the compiler-specific C runtime DLLs (like msvcr90.dll). It does not refer to msvcrt.dll, which *is* shipped with the operating system > Is there an option to static link using mingw's gcc? No. > Also sobering is > "the CRT DLL is no longer considered a system file" from > http://support.microsoft.com/kb/326922 That again is confusingly written, the term "CRT DLL" there must refer to the msvcr[789]*.dll files, not msvcrt.dll. > Does this mean depending on msvcrt.dll is unstable? Hardly. Check for instance what C runtime DLL notepad.exe imports. Yes, our old friend msvct.dll. Still in Windows 7. --tml |
From: Greg C. <gch...@sb...> - 2009-11-23 21:52:30
|
On 2009-11-23 20:51Z, Roger Pack wrote: > > Keith Marshall wrote > > >> What; you mean explicitly to msvcr71.dll, or some later version? >> Sorry, but no can do. ... we aren't permitted to redistribute an appropriate version > > So, let me make sure I understand. It links by default to msvcrt.dll > because that's the one developer's have on their machines, by default, And because it's the one end users always have: they need it, too. > however, we as developers *can* link against a different version > and/or distribute our released binaries with that version, if desired? The question is whether you can redistribute a different version of the msvcrt dll with your mingw app. IIRC, their EULA doesn't let you do that; even if it did, there'd be an issue if your app is GPL. > http://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application > > provides some food for thought... They're talking about building apps with msvc, not gcc. > Is there an option to static link using mingw's gcc? gcc can link static libraries statically; but the msvcrt library that MinGW uses is supplied with the OS only as a dll, which you cannot link statically. > Also sobering is > "the CRT DLL is no longer considered a system file" from > http://support.microsoft.com/kb/326922 > > Does this mean depending on msvcrt.dll is unstable? It means that MinGW won't be able to depend on it being provided with the OS, if ms ever stops providing it with the OS. So far, they haven't stopped. |
From: Keith M. <kei...@us...> - 2009-11-23 21:57:48
|
On Monday 23 November 2009 20:51:35 Roger Pack wrote: > It does make sense that there's nothing that can be done, except > perhaps linking to a newer version of msvcrt.dll. > > Keith Marshall wrote > > > > What; you mean explicitly to msvcr71.dll, or some later version? > > Sorry, but no can do. ... we aren't permitted to redistribute > > an appropriate version > > So, let me make sure I understand. It links by default to > msvcrt.dll because that's the one developer's have on their > machines, by default, Nope; it links to msvcrt.dll because that's what END USERS are guaranteed to have. > however, we as developers *can* link against > a different version and/or distribute our released binaries with > that version, if desired? If you, as a developer, choose to link to some other version, then you have to have a licence to redistribute that version. AFAIK, such licences must be PURCHASED from Microsoft; I may be wrong, but I don't think the EULAs of MSVC-Express versions permit it. > Is there an option to static link using mingw's gcc? Not to the OS provided runtime library. You would need to find, or create an alternative runtime, which you could build as a staticly linkable library, but that takes you out of MinGW's bailiwick. -- Regards, Keith. |
From: Roger P. <rog...@gm...> - 2009-12-04 00:48:03
|
>> however, we as developers *can* link against >> a different version and/or distribute our released binaries with >> that version, if desired? > > If you, as a developer, choose to link to some other version, then > you have to have a licence to redistribute that version. AFAIK, > such licences must be PURCHASED from Microsoft; I may be wrong, but > I don't think the EULAs of MSVC-Express versions permit it. Thank you everyone, for your replies. So if I understand correctly, I *could* link against other versions of msvcrt.dll, however it doesn't link by default because 1) the maintainers of mingw would have to have a license of MSVC in order to distribute the dll's and 2) the developers who use mingw would need to re-distribute the newer msvcrt.dll with their apps, thus they would also need a license. I.e. the only *real* obstacle is money for licensing, not a technical limitation. Guess that's reasonable. As a note, here's the license from MSVC 2008 express. This file exists: ./Microsoft Visual Studio 9.0/VC/redist/x86/Microsoft.VC90.CRT/msvcr90.dll In the file redist.txt it says "The following list is a list of files available with Microsoft Visual Studio 2008 for redistribution under the Visual Studio 2008 license. If the Microsoft software you have licensed is not Visual Studio 2008, only the files that are installed by the Microsoft software may be redistributed under such license." and includes the above msvcr90.dll So it's not totally clear to me whether you can redistribute it or not... >> Is there an option to static link using mingw's gcc? > > Not to the OS provided runtime library. You would need to find, or > create an alternative runtime, which you could build as a staticly > linkable library, but that takes you out of MinGW's bailiwick. Interesting. I wonder how MSVC does it... The existence of C:\Program Files\Microsoft Visual Studio 9.0/VC/lib/msvcmrt.lib within VC 2008 express might be a clue. Cheers. -r |
From: Tor L. <tm...@ik...> - 2009-12-04 01:17:54
|
> Interesting. I wonder how MSVC does it... > The existence of C:\Program Files\Microsoft Visual Studio 9.0/VC/lib/msvcmrt.lib > within VC 2008 express might be a clue. That is an import library for msvcr90.dll (not msvcrt.dll) and not a static library. Just like MinGW's libmsvcrt.a is an import library for msvcrt.dll. (OK, so the msvcrt.lib in MSVS9 does contain a bunch of static objects too, it seems, but I assume those are some compiler+runtime internal ones, they don't contain normal C (or C++) library functions.) --tml |