Albert ARIBAUD a écrit :
> David Brownell a écrit :
>> On Wednesday 25 November 2009, Albert ARIBAUD wrote:
>>> Dean Glazeski a écrit :
>>>> This patch shouldn't be necessary. I have the libftdi version working
>>>> fine with current head. I think this might be an issue with mixing
>>>> libraries in the configure command. I've responded to the next email
>>>> with more information.
>>>>
>>>> // Dean Glazeski
>>> Well it shouldn't be, but it is :) and no, this is not an issue of
>>> mixing libraries, not in my case anyway, as my ./configure only
>>> configures the opensource lib (and I suspect it to be the case for the
>>> OP too).
>>>
>>> On my system, libftdi, built from git, places its header files in
>>> ${prefix}/include/libftdi, and thus compiling for it requires a -I --
>>> even worse, for libftdi examples, it requires -isystem rather than -I.
>> Sounds like a libftdi isssue ... you might ping that list
>> to see what they have to say, and if it's fixable before
>> the 0.17 release goes out.
>>
>> Or maybe you should just find better config options to use.
>> I see that recent Debian doesn't need /usr/include/ftdi, for
>> example:
>>
>> http://packages.debian.org/squeeze/amd64/libftdi-dev/filelist
>>
>> Maybe they treat this /usr/include/ftdi thing as a bug and
>> work around it ... :)
>
> Hmm... Checking the versions, Debian is talking about 0.16. I'm using
> the git code, which is 1.0-ish, and has a commit to add CMake rules. Now
> if I have to choose between where the Debian folks say the LIBFTDI 0.16
> headers should go, or where the LIBFTDI folks say 1.0 headers should go,
> then... I'd ask pkg-config or search, rather that take one single stance. :)
>
> Amicalement,
The FTDI folks are looking into it as it may be a difference between
their cmake and autoconf scripts--and I used cmake to build libftdi.
However, they agree that the right way is pkg-config or libftdi-config,
which will tell where the headers ended up -- even in cases where
someone configure libftdi with an exotic prefix or include path.
Amicalement,
--
Albert.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
