guile-devel
[Top][All Lists]
Advanced

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

Re: native Win32 guile 1.7.0


From: stefan
Subject: Re: native Win32 guile 1.7.0
Date: Fri, 30 May 2003 11:27:37 +0200 (CEST)

On Fri, 30 May 2003, Kevin Ryde wrote:

> stefan <address@hidden> writes:
> >
> >       * posix.c (s_scm_putenv): Disable use of unsetenv() for the
> >       mingw32 build.
> >
> > #ifndef __MINGW32__
>
> It'd be good autoconf style to test unsetenv with AC_CHECK_FUNCS if
> it's not always available.  In particular that way it gets used if
> added to mingw in the future.
>
> Perhaps environ could be munged directly if unsetenv doesn't exist.
> Might end up being a memory leak.  Probably not ideal to silently do
> nothing.

I just added a check for unsetenv() in the configure script and used it in
posix.c appropiately for mingw32 hosts.  Which means that a
putenv("name="); would remove the environment variable 'name'.

With the last changes in 'numbers.h' all of the errors in the error.log I
posted earlier disappear, i.e. using _copysign, _isnan and _finite solved
the problems in the 'numbers.test'.

Remaining issues about the cross-build:

 * I do use a special 'guile.cache' file as cache file for the configure
   script.  The file defines some tests to be done and chached.  I think
   this is normal for a cross-build.

 * The 'fileblocks.o' must be removed in configure before configure'ing.
   This is due to the macro AC_STRUCT_ST_BLOCKS.

 * For the 'guilereadline.dll' I need to add -lpthread to the linker line.
   That is because the scm_cell() inline function in 'inline.h' uses
   pthread_getspecific().  We could avoid that dependency by making
   scm_getspecific() a real function in 'libguile.dll' and not a simple
   macro.  Thus all the pthread dependencies are kept within
   'libguile.dll'.

Cheers,
        address@hidden





reply via email to

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