Hi all,
I found this a while ago (on an SAP mailing list, if I recall
correctly) and I thought I share this.
When compiling native extensions on windows using Visual Studio 2005,
loading the resulting library results in an ungly Runtime Error.
This seems to be caused by some information missing from the library,
which is included automatically when using VC6. To fix this problem,
execute
mt.exe -outputresource:extension_name.so;2 -manifest
extension_name.so.manifest
Replacing extension_name with the correct extension name, of course.
I have modified my mkmf.rb file to include this line:
mfile.print “\n\tmt.exe -outputresource:$(DLLIB);2 -manifest
$(DLLIB).manifest” if $mswin
right under
mfile.print LINK_SO
So far, I have tested this for some of my own extensions, as well as
ruby-debug. I also use it to try and compile the Ferret c extension,
but am having some problems - but those are caused by problems with
the Ferret code itself, not the extension loading mechanism.
Cheers,
Max
On 8/14/06, Max M. [email protected] wrote:
When compiling native extensions on windows using Visual Studio 2005,
loading the resulting library results in an ungly Runtime Error.
How? You don’t. Visual Studio 2005 does not produce extensions
compatible with VC6 output.
I ran out of time writing up stuff last week, but I will be sending
something to Microsoft this week about this sort of issue.
-austin
On 8/15/06, Austin Z. [email protected] wrote:
On 8/14/06, Max M. [email protected] wrote:
When compiling native extensions on windows using Visual Studio 2005,
loading the resulting library results in an ungly Runtime Error.
How? You don’t. Visual Studio 2005 does not produce extensions
compatible with VC6 output.
Did you read the post? It wasn’t a question… I am aware there are
incompatibilities,
however I have been able to compile some extensions quite successfully
with
VS2005.
One of the problems (which is fixed by the mt.exe call in the OP) is
that the libraries produced by VS2005 are apparently missing some
metainformation.
Another problem I have found through tinkering with Ferret is that in
win32.h fclose() gets redefined to rb_w32_fclose(). rb_w32_fclose does
not work in vs2005-compiled code, it only seems to want to close files
that have been opened with the corresponding rb_open.
However, as Ferret makes extensive use of fseek(), for which there
seems to be no rb_* equivalent, the only way for me to fix this
currently appears to be by undefining fclose() before including
stdio.h. This works perfectly for compiling Ferret.
I tried compiling ruby-debug (works fine) and the rcov extension (no
success).
I fact, the current win32 gem for ruby-debug was compiled with VS2005.
Max
On 8/15/06, Max M. [email protected] wrote:
Did you read the post? It wasn’t a question… I am aware there are
incompatibilities,
Yes, I did. I’m trying to discourage anyone from using your
instructions because they will ultimately come to greater problems
trying to use them because of what I consider to be stupid decisions
by Microsoft toward SxS assemblies.
The mt call you make only masks the problems that will arise.
I strongly recommend that you do NOT mix Windows compiler versions.
Doing so is just asking for trouble.
-austin
I strongly recommend that you do NOT mix Windows compiler versions.
Doing so is just asking for trouble.
Fair enough.
Is there a write-up anywhere detailing the changes that cause the
incompatibilities?
Max