Hello,
I have tried to build SVN1676 using MinGW/msys and it failed during
compilation of jim.c because of a already declared environment. Also
checking for "environ in stdlib.h" at least keeps the build-process
running here, a patch is attached.
Please allow me a not so small side-note from an "end-user"
point-of-view triggered by the latest discussions on this mailing list
and non related to the topic of this e-mail and also not related to the
technical background which caused these discussions;
First of all: thanks for improving and extending OpenOCD.
Yesterday a tried to flash/debug a LPC2148 (SVN1651, Win32 binary built
with MinGW, Host WinXP, JTAGkey, Olimex LPC-P2148). I'm used to read and
try a lot when using a new OpenOCD version but for the first time I have
seen OpenOCD crash completely several times. Maybe just caused by my
modification in configure.in but I don't know yet. I planned to create
a step-by-step list how to reproduce the issue with a log-file and
send it to this list but the latest discussions made me insecure. Should
I wait until things have been settled and try with a later SVN version?
Should I use the latest SVN version and try again even if it's under
heavy development? If I go back to SVN version xxxx/Release 0.1 and try
again, will someone be interested if the report is for an older version?
Anyway - is it of any worth for the project/the maintainers if an
end-user like me keeps track with trunk for tests it and send feedback?
If the developers/maintainers expect that people from outside the "inner
circle" do some tests and give feedback the "trunk" should always be in
some kind of working state with no known "show-stoppers". The
documentation/target-library-files should provide just enough
information/templates that binaries made from trunk can be tested by
someone without in-depth knowledge of the source-code who does not not
read every message in the list.
I'd like to suggest that branches should be created for major
modifications that need some development-time and integrate them into
trunk once thinks have been settled and tested a little bit. Cortex-M3
support (and XScale too IRC) has been developed like this and I
personally found that this has been a good approach.
Regards,
Martin Thomas
--- configure.in_1676 Fri May 8 17:37:39 2009
+++ configure.in Fri May 8 18:10:19 2009
@@ -788,11 +788,12 @@
AM_PROG_CC_C_O
AC_PROG_RANLIB
-# Look for environ alternatives. Possibility #1: is environ in unistd.h?
-AC_MSG_CHECKING([for environ in unistd.h])
+# Look for environ alternatives. Possibility #1: is environ in unistd.h or
stdlib.h?
+AC_MSG_CHECKING([for environ in unistd.h and stdlib.h])
AC_COMPILE_IFELSE([
#define _GNU_SOURCE
#include <unistd.h>
+#include <stdlib.h>
int main(int argc, char **argv) { char **ep = environ; }
], [
AC_MSG_RESULT([yes])
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
