detect mingw in source file

[starwing]

Hi,

if you compile luasocket without makefile, you must define LUASOCKET_INET_PTON, so why not we make things easier? this is my patch:

diff --git a/src/inet.h b/src/inet.h
index 1f1a96a..55cf61c 100644
--- a/src/inet.h
+++ b/src/inet.h
@@ -22,6 +22,10 @@
 #define LUASOCKET_INET_ATON
 #endif

+#ifdef __MINGW32__
+#define LUASOCKET_INET_PTON
+#endif
+
 int inet_open(lua_State *L);

 const char *inet_trycreate(p_socket ps, int family, int type);

this makes compile easier.

btw, it's better to add a .def file to export all symbols in windows, thus we needn't define __declspec(export) anymore.

[sam-github]

I prefer the __declspec(export) over .def file, on most projects, the windows .def file drifts out of sync with the code.

[starwing]

but why not use LUALIB_API?

[greatwolf]

LUALIB_API is not the right macro to use. This is how luaconf.h defines it on my setup:

/* Linkage of public API functions. */
#if defined(LUA_BUILD_AS_DLL)
#if defined(LUA_CORE) || defined(LUA_LIB)
#define LUA_API     __declspec(dllexport)
#else
#define LUA_API     __declspec(dllimport)
#endif
#else
#define LUA_API     extern
#endif

#define LUALIB_API  LUA_API

As you can see, LUALIB_API isn't going to preprocess into __declspec(dllexport) unless we're building lua itself as a dll. Without that dllexport decoration, the functions will never make it into the the export table of the dll we're building.

[ewestbrook]

In general, we rely on the presence of _WIN32 to detect Windows builds (as is commonly done).

In Windows builds, LuaSocket uses the __declspec(dllexport) directive for the few LUASOCKET_API functions that need to be exported by LuaSocket.

In this particular case, inet.h uses the _WIN32 condition to define LUASOCKET_INET_PTON for all Windows builds -- including MinGW.

Does this satisfy your case? Please add a response if further action is needed, otherwise it will be assumed that all is well.

[alerque]

The rockspec's use of LUASOCKET_INET_PTON was changed in #383 and released in v3.1.0. If some Windows folks from here can look into this and identify if changes need to be made to the makefile too I would be willing to facilitate a PR to get this issue closed.

[alerque]

It seems like this issue might be resolved in recent releases. If anybody has evidence to the contrary feel free to pipe up with a comment and I'll re-evaluate.