RE: [avrdude-dev] Loaddrv in windows subdir linking with libusb

[Eric Weddington]

> -----Original Message-----
> From: Joerg Wunsch [mailto:address@hidden 
> Sent: Friday, August 11, 2006 4:36 AM
> To: address@hidden
> Cc: Eric Weddington
> Subject: Re: [avrdude-dev] Loaddrv in windows subdir linking 
> with libusb
> 
> As Eric Weddington wrote:
> 
> > My problem is that the loaddrv executable in the /windows subdir is
> > attempting to link with libusb, which it shouldn't be.
> 
> Well, it shouldn't really hurt though (and didn't when I've been
> trying to build it on Win32 back when implementing USB support).
> As loaddrv doesn't reference anything out of libusb, the linker is
> supposed to effectively ignore that file then.

Good point. However, I'm getting a link error saying that it can't find
libusb. At this point I would just like to build avrdude as is, without usb,
so I have a baseline to start from when I do get around to linking that in.

Also, I'm just trying to test a series of patches that don't need libusb at
this point. More below...


> > I need to know how this is getting configured to do this and how to
> > disable this. I can't get avrdude to build right now because of
> > this.
> 
> The issue is that AC_CHECK_LIB, when successful, by default simply
> adds the respective -l statement to the global variable LIBS which is
> then used for all link jobs within the project.
> 
> I've specified an explicit action to take in AC_CHECK_LIB now, and
> implemented a new variable LIBUSB that gets only substituted into
> avrdude_LDADD, so the other link jobs will not be affected.  I
> verified this works on Unix, i. e. I'm still linking against -lusb
> when the check for libusb has been positive, so I assume this will
> also fix your situation.

I'll try it out. Thanks for doing this.

 
> I take this you are now busy preparing a new WinAVR release, are you?

Yes. But as always this is going to take some time.

> I think the current feature set of AVRDUDE would make it worthwhile to
> get out a new release anytime soon.  We've got a number of bugfixes,
> signature verification, ATmega256x support, and last not least
> high-voltage programming support for the STK500.  I wish I knew a bit
> more about XSL to allow for extracting the high-voltage parameters out
> of the XML files for the remaining supported AVRs within half an hour
> or so...

Did you look into xmlstar?


> Anyway, we should now start catching up with all the bugreports and
> patches that have been sent in lately, and then aim for a new release.
> Do you think you could contribute to that part, Eric?

Yes. That's what I was actually working on when I ran into this problem. I'm
trying to work on testing 3 patches that was sent in that Matthias Ringwald
recently posted about. I've also been taking a look at some of the other
patches and bug reports in the trackers. Also, this time I want to try and
get libusb working for the Windows version.

Eric