[geda-user] Banging my head against the guile-for-windows wall

[Kai-Martin Knaak]

Hi guys.
You may remember that there is no current windows version of geda-gaf.
I'd really like to see some of the improvements of the last years in
the windows version too. So I keep trying. The road block is the
dependence on guile 2. Unfortunately, minipack and MXE both only support
guile 1.8 out of the box. Last weekend I decided to give MXE a shot
(again).

So this is what I did:

1) git cloned the current master branch of MXE

2) build the environment with
make gcc

3) bumped the version in guile.mk :

/----------------
PKG := guile
#$(PKG)_IGNORE := 2%
$(PKG)_VERSION := 2.0.11
$(PKG)_CHECKSUM := ae86544b39048a160f4db1c0653a79b40b6c1ee6
(...)
define $(PKG)_BUILD
(...)
'$(TARGET)-gcc' \
-W -Wall -disable-Werror -ansi -pedantic \
'$(2).c' -o '$(PREFIX)/$(TARGET)/bin/test-guile.exe' \
`'$(TARGET)-pkg-config' guile-$(call SHORT_PKG_VERSION,$(PKG))
--cflags --libs` \ -DGUILE_MAJOR_MINOR=\"$(call
SHORT_PKG_VERSION,$(PKG))\" endef
\----------------

In addition I added "-disable-Werror". The original "-Werror" flag made
the build process exit at the config stage. It complained about the
type "long long", which allegedly is not supported in c90.

With this flag warnings are ignored and the build declares success.

However, I get immediate segfault if I start the resulting guile.exe with
wine32. This should bring up a simple command line environment. Instead,
I get:
/----------------------------
/usr/local/src/minipack/result/bin$ wine32 guile.exe
wine: Unhandled page fault on read access to 0x0000001d at address
0x709ca8eb (thread 0040), starting debugger... Unhandled exception: page
fault on read access to 0x0000001d in 32-bit code (0x709ca8eb). Register
dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:709ca8eb ESP:004327c0 EBP:00000015 EFLAGS:00010202( R- -- I - -
- ) EAX:00c7ffc0 EBX:709c2760 ECX:00000004 EDX:00000000
ESI:00000000 EDI:00000000
(...)
00000022 (D) Z:\usr\local\src\minipack\result\bin\guile.exe
00000033 0
00000032 0
00000021 0
0000002e 0 <==
\------------------------------

I am lost here. How would I debug this? Any lead? Would gdb be an option?
What would be the most likely culprit?

---<)kaimartin(>---
PS: My host system is on Debian/testing/jessie, fairly recently updated.
PPS: The main text of this post went to the MXE list, too. Maybe some of
the devs there points me to the right direction.

[Peter Stuge]

The road block is the dependence on guile 2.

Oh fun.

/----------------
PKG := guile
#$(PKG)_IGNORE := 2%
$(PKG)_VERSION := 2.0.11
$(PKG)_CHECKSUM := ae86544b39048a160f4db1c0653a79b40b6c1ee6
(...)
define $(PKG)_BUILD
(...)
'$(TARGET)-gcc' \
-W -Wall -disable-Werror -ansi -pedantic \
'$(2).c' -o '$(PREFIX)/$(TARGET)/bin/test-guile.exe' \
`'$(TARGET)-pkg-config' guile-$(call SHORT_PKG_VERSION,$(PKG))
--cflags --libs` \ -DGUILE_MAJOR_MINOR=\"$(call
SHORT_PKG_VERSION,$(PKG))\" endef
\----------------
In addition I added "-disable-Werror". The original "-Werror" flag made
the build process exit at the config stage. It complained about the
type "long long", which allegedly is not supported in c90.

Mh, don't do this. Fix up the guile source code locally instead.

With this flag warnings are ignored and the build declares success.

But who knows what the code will do? There may be actual programming
errors in the source which the compiler identifies as warnings...

However, I get immediate segfault if I start the resulting guile.exe with
wine32.

My guess is that the code is broken somehow. Maybe compiler warnings
would be enough to find the problems, maybe it requires a deeper look.

/----------------------------
/usr/local/src/minipack/result/bin$ wine32 guile.exe
wine: Unhandled page fault on read access to 0x0000001d at address
0x709ca8eb (thread 0040), starting debugger... Unhandled exception: page
fault on read access to 0x0000001d in 32-bit code (0x709ca8eb). Register
dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:709ca8eb ESP:004327c0 EBP:00000015 EFLAGS:00010202( R- -- I - -
- ) EAX:00c7ffc0 EBX:709c2760 ECX:00000004 EDX:00000000
ESI:00000000 EDI:00000000
(...)
00000022 (D) Z:\usr\local\src\minipack\result\bin\guile.exe
00000033 0
00000032 0
00000021 0
0000002e 0 <==
\------------------------------

So the stack has been overwritten with zeros. The actual error is
likely somewhere earlier, before the current stack frame, and this
error state doesn't really tell much.

I am lost here. How would I debug this? Any lead? Would gdb be an option?

You're asking about debugging Windows binaries using WINE on the
geda-user list. Even if WINE can actually be used for debugging
I don't think you'll get very good replies here. :)

I would say that the way to debug Windows binaries is to use the MSVC
debugger. You would need an actual Windows system (either VM or PM)
with an appropriately high MSDN-level of Visual Studio installed to
get the debugger you need. I don't even know exactly what you need.

I don't know if gdb supports Windows.

What would be the most likely culprit?

Impossible to say.


I would work with the source code instead. First fix all warnings
found by the compiler. Maybe also enable additional warnings and fix
those. If the shell still crashes, debug by sprinkling
printf("messages"); fflush(stdout);
all over the code, to find where the crash happens.

PPS: The main text of this post went to the MXE list, too. Maybe some of
the devs there points me to the right direction.

I think that's a better place to ask than geda-user, but a WINE list
and/or a guile list would probably be much better still.

Or just plow on with the source code. I guess that you will have
learned a lot more about the problem that way before you get any
concrete advice from any list.


Kind regards

//Peter

[Kai-Martin Knaak]

Post by Peter Stuge

Post by Kai-Martin Knaak
In addition I added "-disable-Werror". The original "-Werror" flag
made the build process exit at the config stage. It complained
about the type "long long", which allegedly is not supported in
c90.

Mh, don't do this. Fix up the guile source code locally instead.

Post by Kai-Martin Knaak
With this flag warnings are ignored and the build declares success.

Configure actually checked for long long and determined it to be
supported on my set-up. So I figured, this particular warning can be
safely ignored.

Post by Peter Stuge
But who knows what the code will do? There may be actual programming
errors in the source which the compiler identifies as warnings...

Post by Kai-Martin Knaak
However, I get immediate segfault if I start the resulting
guile.exe with wine32.

My guess is that the code is broken somehow.

And it somehow just affects the cross compile. The very same source
works just fine if built native on Linux.

Post by Peter Stuge
I would work with the source code instead. First fix all warnings
found by the compiler. Maybe also enable additional warnings and fix
those. If the shell still crashes, debug by sprinkling
printf("messages"); fflush(stdout);
all over the code, to find where the crash happens.

This pedestrian approach is known to me ;-)

---<)kaimartin(>---

[Peter Stuge]

Post by Kai-Martin Knaak

Post by Peter Stuge
My guess is that the code is broken somehow.

And it somehow just affects the cross compile. The very same source
works just fine if built native on Linux.

One and the same source often doesn't cross both Linux and Windows
because even though both systems have a C compiler they are still
very very different. The same package being compilable for both
doesn't mean that the same source is actually being used. :)

Post by Kai-Martin Knaak

Post by Peter Stuge
I would work with the source code instead. First fix all warnings
found by the compiler. Maybe also enable additional warnings and fix
those. If the shell still crashes, debug by sprinkling
printf("messages"); fflush(stdout);
all over the code, to find where the crash happens.

This pedestrian approach is known to me ;-)

It's ghetto but it works.


//Peter

[Gabriel Paubert]

Post by Kai-Martin Knaak

Post by Peter Stuge

Post by Kai-Martin Knaak
In addition I added "-disable-Werror". The original "-Werror" flag
made the build process exit at the config stage. It complained
about the type "long long", which allegedly is not supported in
c90.

Mh, don't do this. Fix up the guile source code locally instead.

Post by Kai-Martin Knaak
With this flag warnings are ignored and the build declares success.

Configure actually checked for long long and determined it to be
supported on my set-up. So I figured, this particular warning can be
safely ignored.

Post by Peter Stuge
But who knows what the code will do? There may be actual programming
errors in the source which the compiler identifies as warnings...

Post by Kai-Martin Knaak
However, I get immediate segfault if I start the resulting
guile.exe with wine32.

My guess is that the code is broken somehow.

And it somehow just affects the cross compile. The very same source
works just fine if built native on Linux.

Post by Peter Stuge
I would work with the source code instead. First fix all warnings
found by the compiler. Maybe also enable additional warnings and fix
those. If the shell still crashes, debug by sprinkling
printf("messages"); fflush(stdout);
all over the code, to find where the crash happens.

If you have a debugger, the first thing I do is to run the debugger
to know where the crash happens by getting a stack backtrace at
the point the crash happens.

Gabriel

[Kai-Martin Knaak]

Post by Gabriel Paubert
If you have a debugger, the first thing I do is to run the debugger
to know where the crash happens by getting a stack backtrace at
the point the crash happens.

I execute the guile.exe binary with wine. For useful gdb output wine needs
to be compiled from source with appropriate flags, too (my uninitiated
guess). This is a can of worms I'd rather avoid to open ;-)

---<)kaimartin(>---

[Bob Paddock]

Post by Kai-Martin Knaak
In addition I added "-disable-Werror". The original "-Werror" flag made
the build process exit at the config stage. It complained about the
type "long long", which allegedly is not supported in c90.

Warnings *are* errors, they should not be ignored.

I have found it rare for most GCC based code to compile with anything
less than -std=gnu99.

Rather than disable Werror, remove the -ansi and possibly the
-pedantic, add -std=gnu99.

[Kai-Martin Knaak]

Post by Bob Paddock
Warnings *are* errors, they should not be ignored.
I have found it rare for most GCC based code to compile with
anything less than -std=gnu99.
Rather than disable Werror, remove the -ansi and possibly the
-pedantic, add -std=gnu99.

Fair enough.
To see this amount of warnings in code that is supposed to be the part
of the backbone of the GNU suite is a bit disconnecting, though. This
interpreter was started by gnu-gurus twenty years ago. I'd expect them
to have ironed out this kind of wrinkles long time ago. But who am I
to judge? After all, I wouldn't complain about warnings at all, if the
result would just run...

---<)kaimartin(>---

[Girvin Herr]

Post by Kai-Martin Knaak

Post by Bob Paddock
Warnings *are* errors, they should not be ignored.
I have found it rare for most GCC based code to compile with
anything less than -std=gnu99.
Rather than disable Werror, remove the -ansi and possibly the
-pedantic, add -std=gnu99.

Fair enough.
To see this amount of warnings in code that is supposed to be the part
of the backbone of the GNU suite is a bit disconnecting, though. This
interpreter was started by gnu-gurus twenty years ago. I'd expect them
to have ironed out this kind of wrinkles long time ago. But who am I
to judge? After all, I wouldn't complain about warnings at all, if the
result would just run...
---<)kaimartin(>---

I have a software and hardware background and I treat warnings the same
as errors. The compiler generates a warning when it can't decide if the
programmer really wanted it coded that way or they are real errors.
Therefor, warnings are red flags to programmers to look real hard at the
code to confirm that it will, indeed, run fine with that warned code, or
is it a real error that needs fixing. So, your experience with code
that has compilation warnings could be that the programmer has decided
those warnings were okay. In my case, my released code has no warnings
- period. If I get a warning but I decide the code should work
properly, I change the code to satisfy the compiler, not let it go.
Yes, I have seen released code that still has warnings, but I cringe
when I see it and am very reluctant to run it on my computer because it
reflects on the programmer's quality. If there are warnings, what
other, worse bugs are in there? Sometimes I have no choice but to
accept it, especially if I have no time to dig into the code to fix it.
Girvin Herr

[Kai-Martin Knaak]

Post by Girvin Herr
If there are warnings, what
other, worse bugs are in there?

Lets see...
<set-gcc-flags-to -W -Wall -ansi -pedantic>
<build guile>
<grep log> (6k lines(!)) there are actually quite a few warnings:

(...)
read.c: In function 'try_read_ci_chars':
read.c:983:3: warning: implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
char *chars_read = alloca (num_chars_wanted);
^
read.c:983:22: warning: incompatible implicit declaration of built-in function 'alloca'
char *chars_read = alloca (num_chars_wanted);
^

posix.c: In function 'scm_execl':
posix.c:1144:3: warning: passing argument 2 of 'execv' from incompatible pointer type
execv (exec_file, exec_argv);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
from posix.c:50:
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:118:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execv (const char*, const char* const*);
^
posix.c: In function 'scm_execlp':
posix.c:1173:3: warning: passing argument 2 of 'execvp' from incompatible pointer type
execvp (exec_file, exec_argv);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
from posix.c:50:
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:120:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execvp (const char*, const char* const*);
^
posix.c: In function 'scm_execle':
posix.c:1207:3: warning: passing argument 2 of 'execve' from incompatible pointer type
execve (exec_file, exec_argv, exec_env);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
from posix.c:50:
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:119:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execve (const char*, const char* const*, const char* const*);
^
posix.c:1207:3: warning: passing argument 3 of 'execve' from incompatible pointer type
execve (exec_file, exec_argv, exec_env);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
from posix.c:50:
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:119:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execve (const char*, const char* const*, const char* const*);

(...)


The next warnings look more like scheme issues, rather than c:

ice-9/session.scm:241:11: warning: non-literal format string

(...)

language/ecmascript/function.scm:40:9: warning: possibly unbound variable `<js-array-object>'
language/ecmascript/function.scm:44:43: warning: possibly unbound variable `js-array-vector'

(...)

language/ecmascript/base.scm:227:22: warning: possibly unbound variable `Boolean'
language/ecmascript/base.scm:228:21: warning: possibly unbound variable `String'
language/ecmascript/base.scm:229:21: warning: possibly unbound variable `Number'

(...)

ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:63:0: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:97:49: warning: possibly unbound variable `%readline'
ice-9/readline.scm:125:38: warning: possibly unbound variable `readline-options-interface'
ice-9/readline.scm:156:4: warning: possibly unbound variable `%readline'
ice-9/readline.scm:206:4: warning: possibly unbound variable `*readline-completion-function*'
ice-9/readline.scm:210:2: warning: possibly unbound variable `*readline-completion-function*'
ice-9/readline.scm:213:10: warning: possibly unbound variable `*readline-completion-function*'
ice-9/readline.scm:216:10: warning: possibly unbound variable `*readline-completion-function*'

(...)


and finally the long long warnings I mentioned before:

/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/guile/2.0/libguile/deprecated.h:690:44: warning: ISO C90 does not support 'long long' [-Wlong-long]
SCM_DEPRECATED SCM scm_long_long2num (long long sl);
^
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/guile/2.0/libguile/deprecated.h:691:54: warning: ISO C90 does not support 'long long' [-Wlong-long]
SCM_DEPRECATED SCM scm_ulong_long2num (unsigned long long sl);
^
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/guile/2.0/libguile/deprecated.h:692:21: warning: ISO C90 does not support 'long long' [-Wlong-long]
SCM_DEPRECATED long long scm_num2long_long (SCM num, unsigned long int pos,
^
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/guile/2.0/libguile/deprecated.h:694:30: warning: ISO C90 does not support 'long long' [-Wlong-long]
SCM_DEPRECATED unsigned long long scm_num2ulong_long (SCM num, unsigned long int pos,

\--------------------

Ok, this seems less overwhelming than I thought. The initial c warnings look
familiar. From my scarce coding experiences long long ago "incompatible
pointer type" and "incompatible implicit declarations" ring a serious bell.
I'll accept the challenge and try to (re)learn as I go.

Don't know what to think about the scheme warnings.

Will keep you updated. Just don't hold your breath. I suck at coding and there
is a day job, too...

---<)kaimartin(>---

[gedau-1XeMD6fE9sqV9CSZFf/]

Post by Kai-Martin Knaak

Post by Girvin Herr
If there are warnings, what
other, worse bugs are in there?

Lets see...
<set-gcc-flags-to -W -Wall -ansi -pedantic>
<build guile>
(...)
read.c:983:3: warning: implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
char *chars_read = alloca (num_chars_wanted);
^
read.c:983:22: warning: incompatible implicit declaration of built-in function 'alloca'
char *chars_read = alloca (num_chars_wanted);
^

#include <alloca.h> (or something else depending on your libc there) to
get the declaration of alloca(). Alternatively an ugly workaround is to
declare it manually before the call (in case it's impossible to determine
which .h to include or auto* gets in the way):

extern void *alloca(size_t size);

The extern is optional. Manual declaration of such builtin may cause
problems if the C compiler is clever enough.

Background:

On many systems this is a serious problem: without an explicit
declaration, alloca() will default to return int which is then casted to a
pointer. This happens to work on some systems with sizeof(int) ==
sizeof(char *), but will almost always break on others. With gcc a 32 bit
i386 is normally in the first group while x86_64 is in the second.

Post by Kai-Martin Knaak
posix.c:1144:3: warning: passing argument 2 of 'execv' from incompatible pointer type
execv (exec_file, exec_argv);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:118:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execv (const char*, const char* const*);
^
posix.c:1173:3: warning: passing argument 2 of 'execvp' from incompatible pointer type
execvp (exec_file, exec_argv);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:120:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execvp (const char*, const char* const*);
^
posix.c:1207:3: warning: passing argument 2 of 'execve' from incompatible pointer type
execve (exec_file, exec_argv, exec_env);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:119:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execve (const char*, const char* const*, const char* const*);
^
posix.c:1207:3: warning: passing argument 3 of 'execve' from incompatible pointer type
execve (exec_file, exec_argv, exec_env);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:119:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execve (const char*, const char* const*, const char* const*);

I wouldn't worry much about these: exec() takes const so it won't change
the content, you pass on non-const so you potentially don't care whether
it changes the content. At the end, if exec() doesn't fail, it won't
even matter anymore as exec() won't return. The only case where it would
matter if exec() failed and returned and you'd want to do something with
the args; but even that would matter only in the other direction when you
had a const arg that shouldn't be changed and exec() would take
non-const and change it.

You can suppress these warnings with an explicit cast of the argument.

Regards,

Igor2

[Peter Stuge]

With gcc a 32 bit i386 is normally in the first group while x86_64
is in the second.

Windows uses 32-bit pointers also on 64-bit machines. They locked
themselves and their application developers into 32-bit long ago
and the change would be too big.


//Peter

[Peter Stuge]

Post by Kai-Martin Knaak
read.c:983:3: warning: implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
char *chars_read = alloca (num_chars_wanted);
^
read.c:983:22: warning: incompatible implicit declaration of built-in function 'alloca'
char *chars_read = alloca (num_chars_wanted);
^

This is ugly but if void * and int are the same size it is harmless.

MSDN says the correct header file is malloc.h and that the function
is called _alloca() as opposed to alloca(). Try including the header
and adding a conditional define, into all source files with that
warning.

#include <malloc.h>
#ifndef alloca
#define alloca _alloca
#endif

Post by Kai-Martin Knaak
posix.c:1144:3: warning: passing argument 2 of 'execv' from incompatible pointer type
execv (exec_file, exec_argv);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:118:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execv (const char*, const char* const*);
^

These are harmless, it's a mismatch between const and non-const. When
the function takes const and a non-const is passed, there's no problem.

Post by Kai-Martin Knaak
From my scarce coding experiences long long ago "incompatible pointer
type" and "incompatible implicit declarations" ring a serious bell.

In principle correct, but when the only difference is const vs
non-const it's not so bad.


//Peter

[Gabriel Paubert]

Post by Peter Stuge

Post by Kai-Martin Knaak
read.c:983:3: warning: implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
char *chars_read = alloca (num_chars_wanted);
^
read.c:983:22: warning: incompatible implicit declaration of built-in function 'alloca'
char *chars_read = alloca (num_chars_wanted);
^

This is ugly but if void * and int are the same size it is harmless.
MSDN says the correct header file is malloc.h and that the function
is called _alloca() as opposed to alloca(). Try including the header
and adding a conditional define, into all source files with that
warning.
#include <malloc.h>
#ifndef alloca
#define alloca _alloca
#endif

Post by Kai-Martin Knaak
posix.c:1144:3: warning: passing argument 2 of 'execv' from incompatible pointer type
execv (exec_file, exec_argv);
^
In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
from ../lib/unistd.h:40,
/usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:118:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execv (const char*, const char* const*);
^

These are harmless, it's a mismatch between const and non-const. When
the function takes const and a non-const is passed, there's no problem.

I consider this one a spurious warning, it may probably be silenced by inserting
an useless and ugly cast, but I really wonder on which drugs the compiler
writers were when they decided to add it. You should always be able to pass
a non-const argument to a const parameter.

Post by Peter Stuge

Post by Kai-Martin Knaak
From my scarce coding experiences long long ago "incompatible pointer
type" and "incompatible implicit declarations" ring a serious bell.

Indeed. For the first one there are unavoidable occurences in low level code
but it can fixed by a proper cast (especially if the message is caused
by the distinction between char, signed char and unsigned char, one of
the problems of C and derived languages).

Post by Peter Stuge
In principle correct, but when the only difference is const vs
non-const it's not so bad.

Huh? I consider this message extremely stupid. Passing a const to
a non-const is an error, the other way around should be silently
accepted.

Gabriel

[DJ Delorie]

Post by Gabriel Paubert

Post by Peter Stuge
This is ugly but if void * and int are the same size it is harmless.

I've seen way too many platforms where pointers and "int" are
different sizes, to give this one a pass...

Worse, on the msp430, large-model pointers are neither int-sized nor
long-sized. Not that gEDA will ever run on an msp430 ;-)

Post by Gabriel Paubert
I consider this one a spurious warning, it may probably be silenced by inserting
an useless and ugly cast, but I really wonder on which drugs the compiler
writers were when they decided to add it. You should always be able to pass
a non-const argument to a const parameter.

You're confusing a const argument with an argument which is a *pointer
to* a const value. It's the latter that gcc is warning about, because
the pointed-to types are different.

One could still argue that gcc should ignore pointer-to-nonconst
passed as pointer-to-const (and perhaps the trunk gcc does) but
otherwise the logic is sane - the pointers point to different types.
It's like passing "struct foo *" when the function wants "struct bar *".

[Gabriel Paubert]

Post by DJ Delorie

Post by Gabriel Paubert

Post by Peter Stuge
This is ugly but if void * and int are the same size it is harmless.

I've seen way too many platforms where pointers and "int" are
different sizes, to give this one a pass...
Worse, on the msp430, large-model pointers are neither int-sized nor
long-sized. Not that gEDA will ever run on an msp430 ;-)

Post by Gabriel Paubert
I consider this one a spurious warning, it may probably be silenced by inserting
an useless and ugly cast, but I really wonder on which drugs the compiler
writers were when they decided to add it. You should always be able to pass
a non-const argument to a const parameter.

You're confusing a const argument with an argument which is a *pointer
to* a const value. It's the latter that gcc is warning about, because
the pointed-to types are different.

No, I don't confuse them, I just disagree with the warning.

Post by DJ Delorie
One could still argue that gcc should ignore pointer-to-nonconst
passed as pointer-to-const (and perhaps the trunk gcc does) but
otherwise the logic is sane - the pointers point to different types.

Not different enough to elicit a warning IMHO.

Post by DJ Delorie
It's like passing "struct foo *" when the function wants "struct bar *".

That's where I disagree. Having to add a casts to eliminate this warning
makes the source code uglier without any real benefit.

[Bob Paddock]

Post by Kai-Martin Knaak

Post by Girvin Herr
If there are warnings, what
other, worse bugs are in there?

Lets see...
<set-gcc-flags-to -W -Wall -ansi -pedantic>

What do you get with "-W -Wall -std=gnu99"?