Re: [Patch] Some fixes for the MinGW port

Hi, And best wishes! Kevin Ryde <[EMAIL PROTECTED]> writes: > Cesar Strauss <[EMAIL PROTECTED]> writes: >> -# define LC_MESSAGES_MASK (1 << LC_MESSAGES) >> +# ifdef LC_MESSAGES /* undefined on mingw */ >> +# define LC_MESSAGES_MASK (1 << LC_MESSAGES) >> +# else >> +# define LC_MESSAGES_MA

Re: [Patch] Some fixes for the MinGW port

Cesar Strauss wrote: However, the configure.ac on this branch required an upgrade of my versions of autoconf/automake, which (I think) caused a couple more issues. I will investigate this further. I just needed to copy a certain "config.rpath" file from my gettext installation, to satisfy aut

Re: [Patch] Some fixes for the MinGW port

(Delayed by mail snafu ...) Cesar Strauss <[EMAIL PROTECTED]> writes: > > -extern SCM scm_create_hook (const char* name, int n_args); > +SCM_API SCM scm_create_hook (const char* name, int n_args); > > -extern SCM scm_major_version (void); > -extern SCM scm_minor_version (void); > -extern SCM scm

Re: [Patch] Some fixes for the MinGW port

Cesar Strauss <[EMAIL PROTECTED]> writes: > > Not to mention the common use of spaces within paths, like > "c:\Program Files". It is a recipe for trouble ;-) . Yes. I think autoconf/automake/libtool had trouble with those for a while, let alone what slackness an actual package might have. _

Re: [Patch] Some fixes for the MinGW port

Kevin Ryde wrote: Thanks. Though I think the best advice concerning drive letters is "don't do that" :-). Not to mention the common use of spaces within paths, like "c:\Program Files". It is a recipe for trouble ;-) . ___ Bug-guile mailing list

Re: [Patch] Some fixes for the MinGW port

Kevin Ryde wrote: Cesar Strauss <[EMAIL PROTECTED]> writes: +;; SIGBUS is not present on mingw +(if (defined? 'SIGBUS) +`((,SIGBUS . "Bad memory access (bus error)")) + '())) Thanks, I made

Re: [Patch] Some fixes for the MinGW port

Kevin Ryde wrote: Actually, portability things are being tackled first in the 1.8 branch, then merged into the head periodically. I switched to the 1.8 branch. It fixes all the issues I raised, thanks! However, the configure.ac on this branch required an upgrade of my versions of autoconf/au

Re: [Patch] Some fixes for the MinGW port

Cesar Strauss <[EMAIL PROTECTED]> writes: > > + ;; SIGBUS is not present on mingw > + (if (defined? 'SIGBUS) > + `((,SIGBUS . "Bad memory access (bus error)")) > + '())) Thanks, I made a similar change.

Re: [Patch] Some fixes for the MinGW port

Cesar Strauss <[EMAIL PROTECTED]> writes: > > - The colon, when used as a delimiter in a sed command, conflicts with > paths that include a drive letter (e.g. 'c:/mingw/bin'). > > - -e s:@-bindir-@:${bindir}: \ > + -e 's|@-bindir-@|${bindir}|' \ Thanks. Though I think the best adv

Re: [Patch] Some fixes for the MinGW port

Cesar Strauss <[EMAIL PROTECTED]> writes: > > The attached patch addresses the following issues on MinGW, when > building the CVS HEAD version of guile: Actually, portability things are being tackled first in the 1.8 branch, then merged into the head periodically. There's some mingw pthread fixes

[Patch] Some fixes for the MinGW port

Hi, The attached patch addresses the following issues on MinGW, when building the CVS HEAD version of guile: - The SCM_API tag is missing on some exported symbols; - The LC_MESSAGES macro and the SIGBUS signal are not available on MinGW. - The colon, when used as a delimiter in a sed command, co

Re: Win32/MinGW port

Nils Durner <[EMAIL PROTECTED]> writes: > > As there are no signals on Win32, I *think* it is okay to just "ifndef > MINGW" the code. That might be worth trying. (But not with ifdef mingw, rather a test for missing funcs or features. There's already been mingw-specific conditionals that became b

Re: Win32/MinGW port

> How bad are the missing bits? It's not too bad. pthreads-win32 is fairly complete and working. The mentioned functions are missing because Windows lacks the concept of signals altogether. > Should configure reject it because > there's no pthread_sigmask, or is there something the code can do to

Re: Win32/MinGW port

Nils Durner <[EMAIL PROTECTED]> writes: > > Yes, but some functions are not supported by pthreads-w32. How bad are the missing bits? Should configure reject it because there's no pthread_sigmask, or is there something the code can do to cope? ___ Bug-

Re: Win32/MinGW port

>> scmsigs.c:157: warning: implicit declaration of function >> `pthread_sigmask' > > Does it have pthreads? Yes, but some functions are not supported by pthreads-w32. > Did you ask for them, or did configure wrongly > decide to use them? No, I didn't ask. Nils ___

Re: Win32/MinGW port

Nils Durner <[EMAIL PROTECTED]> writes: > > scmsigs.c:157: warning: implicit declaration of function `pthread_sigmask' Does it have pthreads? Did you ask for them, or did configure wrongly decide to use them? ___ Bug-guile mailing list Bug-guile@gnu.o

Win32/MinGW port

Hi, compiling guile-core-1.8-20061001 under MinGW fails with the following error message: --- gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -Wall -Wmissing-prototypes -W error -MT libguile_la-scmsigs.lo -MD -MP -MF .deps/libguile_la-scmsigs.Tpo -c sc msigs.c -DDLL_EXPORT -DPIC -o .libs/libgui

Re: MinGW port

> Is the execv declaration (in some header file) part of mingw, or Windows? It's part of the Windows SDK. > That's for a function "_execv". Is "execv" also defined by > MS-provided headers? Yes, "for portability". However, the declaration is the same. > If execv is defined as a macro expanding

Re: MinGW port

Ken Raeburn <[EMAIL PROTECTED]> writes: > > Is the execv declaration (in some header file) part of mingw, or > Windows? Looks like mingw process.h. But I've got an idea the "const * const *" is a long-standing MSDOS-ism, presumably carried forward into that horribly bloated overlay manager thing

Re: MinGW port

On Sep 9, 2006, at 14:14, Nils Durner wrote: Hi, first of all, sorry for the late reply. - execv (exec_file, exec_argv); + execv (exec_file, +#ifdef __MINGW32__ + (const char * const *) +#endif + exec_argv); Is the execv declaration (in some header file) part of mingw, or Windows? The SU

Re: MinGW port

Hi, first of all, sorry for the late reply. >> - execv (exec_file, exec_argv); >> + execv (exec_file, >> +#ifdef __MINGW32__ >> + (const char * const *) >> +#endif >> + exec_argv); > > Thanks for the patch, but do you understand exactly what the > Win32/MinGW compiler is complaining about? No, I

Re: MinGW port

Kevin Ryde <[EMAIL PROTECTED]> writes: > In any case, __MINGW32__ conditionals are pretty horrible, I'd much > prefer to see guile not force "-Werror" on unsuspecting users. Or > not do it on mingw at least. I still favor -Werror. It helps catch real errors, and you can usually work around any

Re: MinGW port

Neil Jerram <[EMAIL PROTECTED]> writes: > > do you understand exactly what the > Win32/MinGW compiler is complaining about? The function takes "const char * const *" but the actual parameter is "char **". I've never understood why that should provoke a complaint. Const is a promise by the func t

Re: MinGW port

Nils Durner <[EMAIL PROTECTED]> writes: > Hi, > > the attached patch fixes compiler errors on Win32/MinGW. > - execv (exec_file, exec_argv); > + execv (exec_file, > +#ifdef __MINGW32__ > + (const char * const *) > +#endif > + exec_argv); Thanks for the patch, but do you understand exac

MinGW port

Hi, the attached patch fixes compiler errors on Win32/MinGW. Best, Nils Durner diff -Naur guile-core/libguile/posix.c guile-core.nd/libguile/posix.c --- guile-core/libguile/posix.c Sun Jun 18 00:05:46 2006 +++ guile-core.nd/libguile/posix.c Tue Aug 22 13:42:17 2006 @@ -942,7 +942,11 @@ s