On Mon, 2009-06-15 at 11:08 -0400, Gene Smith wrote: > I did a default configure/make/make install on the latest libftdi source > tarball and it installed at /usr/share/. When I configured openocd with > --enable-ft2232_libftdi it complained about unable to build and run the > libftdi test program. By default, openocd configure is expecting libftdi > to be installed at /usr, not at /usr/share. (The RPM install of libusb > does put it at /usr and there is no problem with it.) > > So when configuring libftdi, setting prefix=/usr fixes the problem. > > Possibly this should be added to the documentation. (There may be other > ways around this but for me this was the most straight forward.)
I think the OpenOCD configure script still stands to be improved, and you are hitting on one of the biggest areas remaining to be addressed. All of the --with options should accept a package's "prefix", such that you should be able to say --with-libftdi=/usr/local and have things work as you expected. Simultaneously, some parts of the existing --with options would need to be converted into --enable options instead (e.g. static vs. shared). This basic --with-<package> idiom comes from the autoconf info pages, not me. Given the apparent desire to support raw (not-installed) library source packages, this means we may also need to allow for additonal options: --with-<package>-includes and --with-<package>-libs. I would hope that such pain could be avoided (probably not with Windows). Beyond this, I have ideas about extending this support such that OpenOCD can build and use both libftdi and ftd2xx driver variants at once, not just one or the other as supported currently. That goes for both the libfdti and presto drivers; it's just some more autotools magic, and it would best be accomplished in the same patch series as the above rework. In total, I see a few hours to a day of work and testing that need to be done (when one considers all of the follow-up to fix cross-platform breakage that is bound to happen). Patches developed that addressed these issues could be accepted quickly; they will make it easier to build OpenOCD on standards-deviant distributions. Presently, we seems to be more deviant in this particular way as an individual package. Personally, I am not motivated to pursue these fixes: patches welcome. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
