From: "grrussel (George Russell)" Date: 2013-06-26T05:34:34+09:00 Subject: [ruby-core:55654] [ruby-trunk - Bug #8569][Open] DLL exports interfere with Win32 Application Embedding Ruby 1.9.3 Issue #8569 has been reported by grrussel (George Russell). ---------------------------------------- Bug #8569: DLL exports interfere with Win32 Application Embedding Ruby 1.9.3 https://bugs.ruby-lang.org/issues/8569 Author: grrussel (George Russell) Status: Open Priority: Normal Assignee: Category: Target version: ruby -v: 1.9.3-p429 Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN I am hitting this same situation in embedding Ruby into an existing application: it manifests as crashes in fclose, which on inspection in the debugger, is shown to be the fclose from the Ruby DLL. It was rather unexpected to have this DLL change the fclose implementation used by the embedding application! Somewhat frustratingly, while this post proposes a solution, it queries if the solution was correct and desirable, and got no response. I am using 1.9.3-p429 with MSVC 2008. Original source: http://www.ruby-forum.com/topic/194276 QUOTE: Posted by Chris Tenbrink (ctenbrink) on 2009-08-28 23:21 I'm trying to embed ruby 1.9.1 in my Windows application and running into some problems. I successfully embedded ruby 1.8.4 in the application, but I'd like to update to use 1.9.1. I'm currently linking to the .lib and .dll files that I built (using the Microsoft Visual Studio 2008 compiler) from the ruby 1.9.1 p243 source. I have similar problems when I link against the 1.9.1 p129 binaries distributed on the www.ruby-lang.org website. The root of the problem is that the ruby dll exports a number of standard library functions that it has redefined. For example, in include/ruby/win32.h from the source distribution, there are a number of statements like the following: #define fclose(f) rb_w32_fclose(f) I assume this was done so that when ruby calls fclose() on win32 systems, it would more closely match what happens on other systems when this function is called. Is this a good assumption? When I build ruby from source (using the instructions found in win32/README.win32), code in mkexports.rb causes these redefinitions to be added to the .def file so that they get exported from the dll. This causes the redefinitions to be viral - anything that links against the ruby .lib and uses the ruby .dll uses the redefined functions. I assume this was done with extension writers in mind so that extension code automatically uses the same redefined std library functions as ruby itself. However, for embedding ruby, I'm not sure this makes sense. I don't mind if ruby does something different with these functions in its own world, but I don't want the rest of my application to change simply because I'm now linking in ruby. I started looking closely at this issue because my application was crashing when the redefined fclose() was called. It turns out that the redefined function calls _get_osfhandle(), and that function doesn't like the passed in parameter. Thus, the invalid parameter handler gets called, which, by default, exits the program. One thing that made me suspicious was that fclose() was redefined for my platform, but fopen() wasn't. I got around this issue by commenting out the code in mkexports.rb that adds these redefinitions to the .def file. This means that the library functions are still redefined within the ruby dll, but NOT for applications that link to the .lib. After building ruby and linking it in with my application, all seems to work out ok. However, I'm reluctant to implement this as a final solution, because I'd prefer not to ship a non-standard ruby dll with my application. In summary, here are my questions: 1) Is it correct to assume that std library functions have been redefined for win32 ruby to maintain consistency within ruby across platforms? 2) Are these redefined std library functions exported from the .dll to ensure extensions use the same code as ruby itself? If so, doesn't this cause problems for applications that embed ruby? 3) If it's really necessary to redefine fclose(), why isn't fopen() redefined symmetrically. 4) Am I missing some configuration setting somewhere that will prevent these redefined functions from being exported from the dll? 5) Is my method of commenting out code to eliminate these exports sound? Thanks for your help. Chris Tenbrink END QUOTE -- http://bugs.ruby-lang.org/