Re: Does guile have serious win32 ambition?

[stefan]

address@hidden wrote:

> I have a reasonable dll working with a 182Kb diff file patched into the 
> 1.4 source tree.
> 
> The most part of these diffs are concerned with the defining of the way 
> functions are imported and exported
> e.g in __scm.h:
> 
> +#if __GUILE_EXPORT__
> +# define GUILE_API __declspec (dllexport)
> +#elif __GUILE_IMPORT__
> +# define GUILE_API __declspec (dllimport)
> +#else
> +# define GUILE_API
> +#endif
> 
> and in all other h files most extern declarations are replaced by
> GUILE_API extern ....
> 
> I must admit these patches are not my own, but I cannot remember where I 
> got them. Credit to whoever did it...

I think this patch has been done by myself. Some time ago I raised this
issue but guile developers are always busy with more pressing issues. This
is good but leaves Win32 developers alone.

Some of my patches referring native Win32 support (MinGW gcc and M$VC)
made it into current guile source anyway. Also we have seen Cygwin people
(Unix emulation layer for Win32) compiling current guile-1.5.4
successfully as DLL and static.

Once again I make the following proposal to make guile compile on a [MinGW
gcc] / [MSVC] installation with Cygwin tools possible. The libtool people
consider the PIC flag for Windows to be `-DDLL_EXPORT' for shared (.lo)
objects. Therefore we can declare something like this in `__scm.h'.

#if defined (__SCM_IMPORT__)
# define SCM_API __declspec (dllimport)
#elif defined (__SCM_EXPORT__) || defined (DLL_EXPORT)
# define SCM_API __declspec (dllimport)
#else
# define SCM_API extern
#endif

This should be done for each library (guilereadline, guilesrfi) with
different *_API and *_(IM/EX)PORT__ symbols.

Now each symbol (data and code) which is meant to be visible for
programs/libraries linking against the produced library *must* declare
these symbols in header files like this:

SCM_API int scm_function (void);
or
SCM_API int scm_data;

Some people always want to leave this issue to the libtool people. But it
seems impossible for the linker (ld for MinGW / link for M$VC) is unable
to resolve the problem. That is why they introduced the DLL_EXPORT define
on the compile line and left it to the programmers of libraries to use it.

I hope this explains some of the questions Unix people have and why this
issue raises from time to time on this mailing list but leaves
unresolved. I would really appreciate comments on all this.

Recently I also sent a patch to guile-developers which implements a
working uname() and the dirent-interface for Win32. Also I tried to
resolve the __CYGWIN__ <-> __MINGW32__ problem with the <winsock2.h>. This
was due to the following: Cygwin has a <winsock2.h>, but is a Unix
emulation layer also having <sys/socket.h>. But <winsock2.h> only defines
a limited subset from <sys/socket.h>. Since the inclusion of these files
was exclusiv (either or) it failed to use <sys/socket.h> on Cygwin. That
has been fixed.

Hope this helps, answers questions, raises some discussion, whatever...
        address@hidden