Build error with SVN trunk

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Build error with SVN trunk

Joerg Wunsch
I've got an older libftdi installed, and my libusb doesn't install the
1.0 header file into a subdirectory (because it's not a 3rd-party
library but an OS-supplied one):

In file included from ../avrftdi.c:43:
../avrftdi_private.h:9:31: error: libusb-1.0/libusb.h: No such file or directory
../avrftdi.c: In function 'avrftdi_open':
../avrftdi.c:650: error: 'TYPE_232H' undeclared (first use in this function)
../avrftdi.c:650: error: (Each undeclared identifier is reported only once
../avrftdi.c:650: error: for each function it appears in.)
*** Error code 1

Please see usbasp.c for how to resolve the include file issue, and
test for TYPE_232H being defined before using it.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Build error with SVN trunk

René Liebscher
Hi,

TYPE_232H undeclared means, that your libftdi is version < 0.20.
There was already a check in configure, which is now reactivated.

Also the check for the include file is changed now, hope this works you.

René

On 16.05.2013 10:34, Joerg Wunsch wrote:

> I've got an older libftdi installed, and my libusb doesn't install the
> 1.0 header file into a subdirectory (because it's not a 3rd-party
> library but an OS-supplied one):
>
> In file included from ../avrftdi.c:43:
> ../avrftdi_private.h:9:31: error: libusb-1.0/libusb.h: No such file or directory
> ../avrftdi.c: In function 'avrftdi_open':
> ../avrftdi.c:650: error: 'TYPE_232H' undeclared (first use in this function)
> ../avrftdi.c:650: error: (Each undeclared identifier is reported only once
> ../avrftdi.c:650: error: for each function it appears in.)
> *** Error code 1
>
> Please see usbasp.c for how to resolve the include file issue, and
> test for TYPE_232H being defined before using it.


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Build error with SVN trunk

Joerg Wunsch
As René Liebscher wrote:

> TYPE_232H undeclared means, that your libftdi is version < 0.20.

Yes, it's still at 0.18, as this used to be the version FreeBSD was
shipping back when I installed it. ;-)  (I could probably upgrade it
again, but the old one at least works well enough for older FTDI
chips.)

> There was already a check in configure, which is now reactivated.

> Also the check for the include file is changed now, hope this works
> you.

Thanks, yes, all works fine now.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Build error with SVN trunk

Hannes Weisbach-2

Am 17.05.2013 um 08:19 schrieb Joerg Wunsch:

> As René Liebscher wrote:
>
>> TYPE_232H undeclared means, that your libftdi is version < 0.20.
>
> Yes, it's still at 0.18, as this used to be the version FreeBSD was
> shipping back when I installed it. ;-)  (I could probably upgrade it
> again, but the old one at least works well enough for older FTDI
> chips.)
avrftdi requires now libftdi-1.0. I don't know why it detected your libftdi-0.x as -1.x.
>
>> There was already a check in configure, which is now reactivated.
Which is not necessary, since avrftdi requires libftdi-1.0 and libftdi-1.0 declares TYPE_232H. This masks an error, where libftdi-0.x is erroneously recognized as libftdi-1.0.
I made the change to libftdi-1.0 because I want to use asynchronous transfers in the future. Plus libftdi-0.x has not been updated since 9 months, so I consider it deprecated. Oh and testing two library versions is too much work ;)

One real problems remains: libftdi-1.0 and libftdi-0.x co-installation, which breaks avrftdi. The clean solution would be to merge all programmers to libftdi-1.0.

Best regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Build error with SVN trunk

Joerg Wunsch
As Hannes Weisbach wrote:

> >> There was already a check in configure, which is now reactivated.

> Which is not necessary, since avrftdi requires libftdi-1.0 and
> libftdi-1.0 declares TYPE_232H. This masks an error, where
> libftdi-0.x is erroneously recognized as libftdi-1.0.  I made the
> change to libftdi-1.0 because I want to use asynchronous transfers
> in the future. Plus libftdi-0.x has not been updated since 9 months,
> so I consider it deprecated.

I disagree.  9 months is nothing in opensource-land.  FreeBSD's
libftdi port is still at 0.20, so please don't break support for older
libftdi versions unless really necessary.  (I can take over the
testing part for that if you want, I've got an FT2232D board and an
FT232H sample module to try with.)

Just have a look at our own release history:

5.5  2007-10
5.6  2009-02
5.8  2010-01
5.10 2010-01 (apparently, I've been so annoyed about a showstopper
              bug in 5.8 that I accidentally skipped 5.9 ;)
5.11 2011-08
6.0  2013-06 ?

As you can see, about 1.5 years between releases are not unusual.
Thus, arguing that some library has not been updated for 9 months is
not useful, IMHO.  Besides, something not being *updated* for a while
can mean it's just good enough for the job, has no known bugs, and is
thus stable.  Not everything on earths suffers from creeping
featurism. ;-)

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Build error with SVN trunk

Hannes Weisbach-2

Am 17.05.2013 um 10:34 schrieb Joerg Wunsch:

> As Hannes Weisbach wrote:
>
>>>> There was already a check in configure, which is now reactivated.
>
>> Which is not necessary, since avrftdi requires libftdi-1.0 and
>> libftdi-1.0 declares TYPE_232H. This masks an error, where
>> libftdi-0.x is erroneously recognized as libftdi-1.0.  I made the
>> change to libftdi-1.0 because I want to use asynchronous transfers
>> in the future. Plus libftdi-0.x has not been updated since 9 months,
>> so I consider it deprecated.
>
> I disagree.  9 months is nothing in opensource-land.  FreeBSD's
> libftdi port is still at 0.20, so please don't break support for older
> libftdi versions unless really necessary.  (I can take over the
> testing part for that if you want, I've got an FT2232D board and an
> FT232H sample module to try with.)
Thanks for the offer. Does it include libusb-1.0 with libusb-compat and libftdi-0.x too? ;)
>
>
> As you can see, about 1.5 years between releases are not unusual.
> Thus, arguing that some library has not been updated for 9 months is
> not useful, IMHO.
I didn't put that very well. My point is, that libftdi-0.x has been superseded by libftdi-1.0 (apparently necessitated by libusb-1.0) and thus is implicitly deprecated. Additionally, patches and bugfixes are apparently not back-ported from libftdi-1.0 to libftdi-0.x.
>  Besides, something not being *updated* for a while
> can mean it's just good enough for the job, has no known bugs, and is
> thus stable.
libusb-1.0 is considered finished and stable. To use libusb-1.0 one has to use libftdi-1.x.

lib{usb,ftdi}-1.0 also feature asynchronous I/O and it is my understanding that with this feature the ftdi_syncbb programmer will be able to work without threading, so we loose one dependency (pthreads) with "just" an update. The async I/O feature will probably also take care of that ominous deadlock problem in avrftdi. As I understand it, threading is just ftdi_syncbb's way of dealing with that.

So IMO, the update brings also the potential for cleaner/easier to understand code (hopefully).

Last but not least, FreeBSD has a libusb-1.0 compatible implementation. I don't know why they are not providing libftdi-1.x.

In retrospect: I didn't anticipate that so much would break. It's probably better to move all programmer at once to a new libusb and/or libftdi. (I still want the update ;))

Best regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Build error with SVN trunk

Joerg Wunsch
As Hannes Weisbach wrote:

> > (I can take over the
> > testing part for that if you want, I've got an FT2232D board and an
> > FT232H sample module to try with.)

> Thanks for the offer. Does it include libusb-1.0 with libusb-compat
> and libftdi-0.x too? ;)

Depends on how you'd recognize FreeBSD's implementation: it's an
OS-supplied libusb that provides three different APIs: 0.1
compatibility, 1.0 compatibility, and native FreeBSD's v2 API.

Yes, the offer to test libftdi-0.20 is meant to work an that platform.

I can also test Solaris/sparc64, which only has libusb-0.1 (to the
best of my knowledge).  I haven't tried compiling libftdi there
though.

> libusb-1.0 is considered finished and stable.

Except see above, Solaris doesn't have it.

Also, I'm not sure whether anyone so far tested all this on Win32
against libusb-1.0.  All I've done so far was against the old
libusb-win32 0.1, but a 1.x version is available now (unlike a couple
of years ago).

> To use libusb-1.0 one has to use libftdi-1.x.

No, one can use libusb-1.0 completely without libftdi. ;-)

I think you meant it the other way: libftdi 1.x requires libusb 1.x.

> lib{usb,ftdi}-1.0 also feature asynchronous I/O and it is my
> understanding that with this feature the ftdi_syncbb programmer will
> be able to work without threading, so we loose one dependency
> (pthreads) with "just" an update.

That's a point, though the only constellation right now that would
really benefit from it is MinGW32 builds.  They are currently the only
platform not offering pthreads.

I'm not opposed to have the code for lib{usb,ftdi}-1.x in, I'd just
like to not see the ability to also work with older versions go away
that quickly (within their limitations, of course).  Sometimes people
simply use older, not very well equipped machines for these tasks,
where they have troubles updating everything to the latest and
greatest bits.  I think it's a nice feature of AVRDUDE of being able
to use whatever "is just there".

> Last but not least, FreeBSD has a libusb-1.0 compatible
> implementation. I don't know why they are not providing libftdi-1.x.

libusb is OS-supplied code there.  libftdi is 3rd-party software which
is simply much less frequently maintained sometimes.  The overall rule
for FreeBSD is often to better be stable rather than bleeding edge.

Before FreeBSD 8.x, they had a completely different USB
implementation.  For this one, they were just using the public
libusb-0.1 implementation, with no chance for a libusb-1.0.  I still
have one old machine where I can test this constellation, too.  Of
course, it's not expected that all the recent FTDI stuff will work
there, but at least proven bits like support for JTAGICEmkII and
AVRISPmkII over libusb-0.1 are supposed to work even in those ancient
environments.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: Build error with SVN trunk

Hannes Weisbach-2
>
> Also, I'm not sure whether anyone so far tested all this on Win32
> against libusb-1.0.  All I've done so far was against the old
> libusb-win32 0.1, but a 1.x version is available now (unlike a couple
> of years ago).
I built for my Windows tests a Win32 executable with libusb-1.0 and it worked fine. Later I read one needs libusbx-1.0 (libusbx is a libusb fork, libusbx.org) for Windows but that seems to be outdated information.
>
>> To use libusb-1.0 one has to use libftdi-1.x.
>
> No, one can use libusb-1.0 completely without libftdi. ;-)
>
> I think you meant it the other way: libftdi 1.x requires libusb 1.x.
Yes ;)

>
>> lib{usb,ftdi}-1.0 also feature asynchronous I/O and it is my
>> understanding that with this feature the ftdi_syncbb programmer will
>> be able to work without threading, so we loose one dependency
>> (pthreads) with "just" an update.
>
> That's a point, though the only constellation right now that would
> really benefit from it is MinGW32 builds.  They are currently the only
> platform not offering pthreads.
>
> I'm not opposed to have the code for lib{usb,ftdi}-1.x in, I'd just
> like to not see the ability to also work with older versions go away
> that quickly (within their limitations, of course).  Sometimes people
> simply use older, not very well equipped machines for these tasks,
> where they have troubles updating everything to the latest and
> greatest bits.  I think it's a nice feature of AVRDUDE of being able
> to use whatever "is just there".
Isn't "compile/run everywhere" some sort of feature creep, too? ;)
Does someone use avrdude on Solaris/sparc64 for good reason?

Being more constructive: How would one go about building such a backwards compatible programmer? Let's take avrftdi as example. I see two options: #ifdef'ing code (I don't like it) to use headers/calls from this or that library or implementing a new programmer (which might share code with the "old" avrftdi). So far, so good. The crux is linking. How tell gcc to link a library against a single object file and use another library for all other object files?
The only option I see is to use some sort of --with flag to select libusb-1.0 or 0.x (and libftdi) and then build only programmers which support this library. If you want backwards compatiblity, use the -0.x and everything is fine. But what if you want to have avrftdi with libftdi-1.0 and JTAGICE or AVRISP with libusb-0.1? Is this even an issue because everyone uses only a single programmer, anyway?

Best regards,
Hannes


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev