[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does guile have serious win32 ambition?

From: Marcel van der Boom
Subject: Re: Does guile have serious win32 ambition?
Date: Thu, 25 Oct 2001 16:16:10 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5+) Gecko/20011023

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.


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)
# define SCM_API extern

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);
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...

Guile-user mailing list

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]