Bug #4585: DLEXT in win32/Makefile.sub is not correct for building with VisualStudio 2008

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 1.9.2p180 (2011-02-18) [i386-mswin32_90]

[felix.petriconi (Felix Petriconi)]

=begin
The value of DLEXT is defined per Win32/Makefile.sub as
#define DLEXT ".so"
which results not in the expected file extension for working under Windows with Visual Studio 2005/2008.

I stepped over this problem when I tried to build Ruby with this compiler and then by creating an extension to C++ code by using the SWIG (2.0.3) library.
As I am not familiar with the build process with MinGW and I do not know if there is the intention to use the .so extension under Windows, I hesitate to patch this in the Ruby repository.

My proposal to change/fix this is

(({!if $(MSC_VER) >= 1400
#define DLEXT ".DLL"
!else
#define DLEXT ".so"
!endif}))

As well I propose to print into the console the complete name of the library that was attempted to load. Currently only the 'require' value is written. Which did not help me solving this problem.

=end

[luislavena (Luis Lavena)]

=begin
Hello,

Ruby's decision to use '.so' for it's C extensions is valid, similar to Python decision to use '.pyd' for their extensions.

Python extensions are valid shared-libraries too (DLL), so the decision of the extension be named '.so' or '.dll' is irrelevant.

The value for DLEXT should not be affecting you or SWIG building an extension using mkmf. If you're not using mkmf, then the problem is how you're building the extension.

DLEXT2 is maintained to offer old '.dll' extensions be loaded, but is not recommended anymore since a Ruby-extension could clash with system dll too (example was sqlite3.so versus sqlite3.dll)

As 'expected file extension', the comment above about Python/Ruby extensions apply.

=end

[felix.petriconi (Felix Petriconi)]

=begin
Hello Luis,

I understand. During further development I already stepped over the fact, that more changes would be necessary to have consistent everywhere the DLL extension, which in the end will cause more trouble. So I propose to close this issue. I will try to get the SWIG documentation updated, because this everywhere still uses the DLL extension which does not work then.
I already pointed at a different location that I have to try to get necessary parts to be build in Visual Studio 2008. But that is no subject here.

Thanks and regards!
=end

[luislavena (Luis Lavena)]

• Status changed from Open to Closed

=begin
Understood, closing this out.
=end