Re: Does guile have serious win32 ambition?

[Marcel van der Boom]

Needless to say I agree...

I'm not all too familiar with the guile sources yet, but it seems to me 
that this is mostly typing stuff in and making sure the builds don't 
break. Given enough typing capacity the time to do this can be made very 
short to have the basics in there without disturbing anything else right?

I reckon that Stefan knows best what other stuff needs to be done, as he 
has done it before.

Marcel

stefan wrote:


> 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
>
>
> _______________________________________________
> Guile-user mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/guile-user


--
Marcel van der Boom
HS-Development BV
Kwartiersedijk 14B
Fijnaart, The Netherlands
Tel. : 0168-468822
Fax. : 0168-468823
Email: address@hidden