On Sun, 2009-06-28 at 01:23 +0000, Martin Panter wrote: > On 27/06/2009, Freddie Chopin <freddie_cho...@op.pl> wrote: > > 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c > > 2. enable dynamic loading of libusb0.dll in ft2232.c > > So why loading libusb rather than libftdi? Is it because libftdi is > only built (or linked to) as a static library on Windows but still > needs the libusb DLL? > > > 3. make it possible to have support for both libftdi and ftd2xx at the same > > time in ft2232.c > > > > n. enable dynamic loading for some other modules - jlink, rlink, presto > > > > n+1. make it possible to have support for both libftdi and ftd2xx at the > > same time in presto.c > > > > I can do the same for linux, but as I have no means for testing I'd rather > > pass that to someone else. With help in testing I can try to do that myself. > > Maybe it's worth trying something like GNU Libtool's libltdl which is > a wrapper around dlopen (Linux), LoadLibrary (Windows) and apparently > stranger things on other platforms as well. I guess you'd still have > to hard code platform specific file names (ftd2xx.dll vs libftd2xx.so > or similar) but it would get rid of most of the platform specific > code. A disadvantage is the added complexity of yet another library to > link to.
I would also suggest using libltdl for these tasks; however, that should be a fairly easy change, after eliminating the existing redundancy. After thinking about this patch some more today, I have become confused about its motives. If the binary cannot be distributed with the FTD2XX driver in it, this patch does not help folks that must compile the code themselves anyway. You cannot have both libftdi and FTD2XX support in the same FT2232 driver binary, so this patch not even allowing testing them both using the same openocd binary (presumably by adding/removing the OS drivers between tests). The later suggestion shows that there could be some value of allowing dynamic loading like this, if you provided a second patch to fix the build system to produce both drivers. However, I think that such a patch will only be possible after adding more full dynamic loading for the JTAG interface drivers. Specifically, the proper place to use dynamic module loading will be to discover the jtag_interface structure from each OpenOCD driver module, adding the structure from each successfully loaded module to populate the interface list. With that, you no longer need this patch either, because the module will fail to load if its required libraries are missing. Personally, I think that I have failed to see the value of this patch, but maybe I have missed something. In contrast to the strategic solution, what problems does this current patch solve for OpenOCD users, today? Without a clear answer to this, I am not sure why we want it. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
