DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22481>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22481 MSVC .NET compiler cannot link against MSVCRT.DLL Summary: MSVC .NET compiler cannot link against MSVCRT.DLL Product: APR Version: 0.9.0 Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: APR AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] MSVC 7 (.NET) compiler no longer links against MSVCRT.DLL . It will only link against MSVCR71.DLL ! This applies to Windows NT, 2K, XP and all forseeable future Windows releases. (Note that the .NET IDE is also knows as Visual Studio 2003.) This is best documented here: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/vclib/html/_crt_c_run.2d.time_libraries.asp The critical lines are: "Any application built with Visual C++ .NET using the /MD switch will necessarily use msvcr71.dll." "If your DLLs pass CRT resources across the msvcrt.dll and msvcr71.dll boundary, you will encounter issues with mismatched CRTs and need to recompile your project with Visual C++ .NET." This has a major implication: Module developers working with pre-built binaries (currently built with MSVC 6, as far as I can tell) and building their module with the MSVC 7 compiler, the module cannot share any C RTL resources used in the module with the APR! Background: I recently examined a problem with mod_filter on Windows. I was using a pre-built version of Apache, but I built the module with the latest MSVC compiler, Version 7, the .NET version. http://cvs.tangent.org/cgi/viewcvs.cgi/*checkout*/mod_filter/mod_filter.c The problem was found in lines like: if ((temp_fd = ap_popenf(plp, filename, O_RDONLY, ...)) < 0) { /* Handle error ... */ } (void)fstat(temp_fd, &sbuf); Again, I am using the MSVC 7 compiler to build this module and the pre-built Apache binaries for Windows. This now fails because the temp_fd is created via Apache.exe's MSVCRT.DLL but the module will get an EBADF (Bad file descriptor) on the fstat() call because it will be calling MSVCR71.DLL, which has a separate set of integer file descriptors (and all other C RTL static data). The immediate workaround is to abandon the APR (at least for files) on Windows and switch back to an open() (or fopen() insteads of ap_pfopen(), perhaps followed by fileno()). Even if the typical Windows software engineer is somewhat informed of this issue in general, s/he will have to recognize that the program is crossing a DLL (or EXE) boundary and getting a different instance of the C RTL if they encounter this problem. This could be a nasty time-sink for anyone trying to work with pre-built versions of Apache. I think that there is serious motivation for apache.org to publish two Windows binary releases of Apache: pre- and post- .NET , both as a service to users and to raise awareness of the issue. The easiest way to demonstrate to yourself that this is a major discontinuity in the Windows platform for extensible programs, you can use the "dumpbin.exe /imports" command on any *.exe or *.dll file. Almost all exisitng file will link to MSVCRT.DLL, but all binaries produced by MSVC 7 compielr will point to MSVCR7.DLL . If apache.org cannot distribute multiple binary releases, then the Windows release notes should have a major heads-up about this issue throughout the Windows release notes. Other major projects also have to deal with this issue. For instance, Python: Announcement from Guido van Rossum http://mail.python.org/pipermail/python-dev/2003-May/035375.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
