On Monday 09 November 2009, Thomas Kindler wrote: > David Brownell wrote: > > On Sunday 08 November 2009, Thomas Kindler wrote: > >> After three hours of fiddling around, I found out, that the windows > >> drivers have to be _installed_ on the system - The script will fail on a > >> system that hasn't seen the dongle. OpenOCD compiles fine after > >> commenting out the configure check. > > > > Curious. Seems like a bug in the D2XX library ... there's > > no reason that a FT_GetLibraryVersion() call should fail > > if the driver isn't installed. A failure should only show > > up when trying to open a device that's not there > > > > Nope. It won't even get to that point. Because we're statically linking > the ftd2xx.lib import-library, the DLL is already loaded on startup, > before entering main. This is not a problem on systems with the driver > installed, because the DLL can be found in c:\windows\system32.
Not being a Windows developer ... I think that translates to "stupid Windows design, which ensures such bugs happen". > (A compiled OpenOCD with ftd2x-support also won't start without the > driver installed). Same root cause. > Perhaps we shouldn't link to ftd2xx.lib at all. Instead, OpenOCD could > use LoadLibrary and GetProcAddress calls to load the .dll at runtime. > > Wouldn't this also solve the GPL problem?! No it wouldn't. We've been over that before. > >> I think, the actual program run should be removed from the configure > >> script entirely. At least, it should have more debugging output. > > > > Patches accepted; a new message would be easy. > > > > Would a patch removing the "run"-step be acceptable? I'll let someone more active in different Win32 configurations chime in here ... this configure.in clause is defending against build a family of bugs that only shows up on Win32. > As I understand, it's left out for cross-compiler builds anyway. So > that's probably why it was never noticed for MinGW builds. > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
