On Fri, 2009-05-08 at 21:54 +0200, Martin Thomas wrote: > 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.
Applied as r1693. This appears like it should do the trick correctly, so I hope it finally solves this problem. [snip] > 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? Well-written crash reports should always be welcome against the current trunk. Be sure that you are using '--enable-maintainer-mode' and do a 'make clean' before testing with the latest versions, as it is definitely possible to end up with a build that crashes that would have worked fine after rebuilding from scratch. > 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? Personally, I prefer feedback against the trunk, though I want to see the project get on a regular release schedule. Right now, I think we are best off focusing our efforts on bringing stability back to the trunk and, from there, heading directly into a testing/release cycle. > 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? Yes! :) Good feedback should always be welcome. I will post another thread that extends this idea quite a ways. [snip] > 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. It looks like we will be headed down a more rigorous path, though the details have yet to be determined. I hope to see this process move forward somewhat quickly, now that the issues have come to a head. Still, we need to adopt policies that will be both efficient for maintainers but will also be effective for the whole OpenOCD community. It will take some time to put a plan together and reach consensus, but you are welcome to contribute to making the process move forward. I recently posted a thread with the subject "openocd policies", and I invite you (and all users) to post a list of suggestions in reply to it. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
