6.4 Windows binaries are linked to libhidapi-0.dll

[cinderblock]

If you run the latest binaries (6.4) for Windows, you get a popup about "libhidapi-0.dll" missing. Looking at the sources, it looks like libhidapi isn't required on Windows builds. Maybe this was accidentally included for some reason?

[dl8dtl]

While it's not strictly required, you'll lose a lot of functionality without HIDAPI. Basically, all the modern Atmel/Microchip programming hardware uses it.
That's why these binaries are linked against it.
Future releases might statically link it, but for 6.4, you have to live with it (or build it yourself without HIDAPI).

[mariusgreuel]

@cinderblock The upcoming AVRDUDE v7 will have statically linked binaries. You can grab a current build here: https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE

[Spongman]

While it's not strictly required

The executable completely fails to run without it. I'd call that "strictly required".

6.4 is a non-functioning release.

[dl8dtl]

While it's not strictly required

The executable completely fails to run without it. I'd call that "strictly required".

It is not strictly required at build time.
Of course, once it has been linked against it, it is required to run that particular binary.

6.4 is a non-functioning release.

Only if you are unable to install libhidapi on your machine. But then, you can still install the source code, and build it yourself. It's opensource. If the configure step doesn't find HIDAPI on your system, it won't use it.

Mind you: if it were not linked against the HIDAPI library, it were completely useless for many people as it wouldn't support all the major Atmel/Microchip tools.

[Spongman]

yes, i was referring to the binary release. it's unusable as it is.

[dl8dtl]

yes, i was referring to the binary release. it's unusable as it is.

It's not unusable.
All you have to do is to install the HIDAPI library.

[dl8dtl]

https://github.com/libusb/hidapi/releases

[dl8dtl]

I just added libhidapi-0.dll to the zip file on Savannah.
Of course, this defeats the ida of a DLL being a shared resource between different applications, but if it's that what Windows users are expecting, be it that way. (In my opinion, installing a DLL in a way where it's not shared is a waste of memory.)

[mariusgreuel]

You may want to add libusb0.dll as well, as avrdude.exe won't run without this DLL.

[dl8dtl]

You may want to add libusb0.dll as well, as avrdude.exe won't run without this DLL.

OK

[cinderblock]

It's not unusable. All you have to do is to install the HIDAPI library.

How do you "install" something without an installer on Windows? There isn't a standard solution as far as I know. IMHO, If HIDAPI isn't mature enough to provide an installer (or at least prescribe where its dll goes), it's not mature enough to be depended on in the Windows ecosystem.

Being somewhat familiar with programming on Windows, I happen to know some locations that will be searched for the needed dll, so I can do this. But it's exactly this kind of headache that prevents other would-be developers from joining the fray.

[dl8dtl]

Please open a ticket with the HIDAPI project if you think they should improve their documentation.

I'm not a Windows guy (not at all), but I'd simply search for a location where obvious other DLLs are found, and drop it there … (Ok, one gotcha on my end was I apparently use an old and now unused name for their DLL. I've been missing their name change.)

[mariusgreuel]

I happen to know some locations that will be searched for the needed dll, so I can do this

No need. With few exceptions, the proper way to solve dependencies on Windows is to ship the required DLLs with the application, and put them side-by-side with the application - note the directory of the exe is the first directory to be searched for DLLs.

The MinGW 6.4 release has been updated to include the required DLLs, so you just copy all files to a folder of your choice, and off you go.

As I mentioned previously, the next release will link all third-party libraries statically for exactly this reason.

[cinderblock]

@mariusgreuel Yes, I happen to know that the first place that is looked in is the same directory. But other people don't know that. Some might guess that and get things to work. However, it's not something that can be relied on, especially without clear instructions from either party.

For instance, one can do the same thing with the libusb, but then you need to rename files on x64 systems. It all works much better if you just install the drivers for the device you're trying to access, which, in turn, install libusb0.dll the "standard" way (whatever they chose is the de facto standard).

I think updating the release zips to include the dependent dlls is the correct step for now. However, I personally think it's weird to see published binary zips change. In any case, I look forward to the statically linked version.

While I appreciate the notion of sharing dlls and saving ram, the reality here is that no other programs, on my system at least, use these same shared libraries. Even if others did, good luck keeping all the versions in sync. Ultimately, we're talking about a comparatively tiny shared library here. IMHO, the headache of dlls is not worth the miniscule memory savings.

@dl8dtl How are others supposed to know how you chose to link to the shared library? If they don't publish a standard, isn't it on you to publish what you expect? As a "windows guy" (and linux guy) and programmer myself, I know where these things look. But 99% of "normal" Windows programs never ask you to mess with such files. Heck, even Linux packages don't do this. So how could Joe User be expected to do this?

[Spongman]

try replacing any random system-installed .so on a linux box with a different-enough version of the same library and you'll realize that shared-library sharing is a myth (outside of system package managers and SxS abstractions).

[dl8dtl]

However, I personally think it's weird to see published binary zips change.

Until Marius appeared now (and I'm glad he does), nobody ever bothered to care about producing Windows binaries. So I (as a non-Windows user) had to provide them for more than 10 years now, cross-compiling them on my FreeBSD development system. I always find that situation curious, so I just tried my best to do the job on that. After the complaints here, adding the DLLs (and thus changing the archive again) was my only option, short of completely removing the Windows binaries on Savannah.

try replacing any random system-installed .so on a linux box with a different-enough version of the same library

That's what shared lib version numbers are for: if there's an API change, the version number is bumped. Executables linked against the old API can then still work, until you remove the old shared lib.

Alas, Windows forgot to add that feature when they did DLLs.

[Spongman]

That's what shared lib version numbers are for: if there's an API change, the version number is bumped. Executables linked against the old API can then still work, until you remove the old shared lib.

Alas, Windows forgot to add that feature when they did DLLs.

that's not a feature. that's a prayer. and it fails to get answered in the worst way.

[dl8dtl]

It's getting religious now.

[cinderblock]

Until Marius appeared now (and I'm glad he does), nobody ever bothered to care about producing Windows binaries.

Yeah, this was holding back avrdude. It used to be much more painful to find a binary. It also used to be much more painful to get a Windows build system set up. I'm also glad Windows is being more officially supported. I think the move to GitHub was the right choice. It will also make the headaches of publishing binaries consistently a thing of the past!

So I (as a non-Windows user) had to provide them for more than 10 years now, cross-compiling them on my FreeBSD development system. I always find that situation curious, so I just tried my best to do the job on that.

Don't get me wrong. I am very thankful. I'm sure I've used your builds in the past.

After the complaints here, adding the DLLs (and thus changing the archive again) was my only option, short of completely removing the Windows binaries on Savannah.

Please don't take this "issue" as a "complaint". I went to install the latest version of avrdude on a supported system and I got an error that I hadn't seen any mention of anywhere. So I opened this issue so that it would at least get on someone's radar. I figured the project, and other users, would like to know if there was a possible problem.

That's what shared lib version numbers are for: if there's an API change, the version number is bumped. Executables linked against the old API can then still work, until you remove the old shared lib.

Alas, Windows forgot to add that feature when they did DLLs.

Many Windows dlls include version numbers in the filename, but this is usually for supporting different versions of dependencies, like the standard libraries. But other techniques can also be used to have multiple versions of the dll installed on the same system. I agree with @Spongman that it's a bit of a prayer relying on numbered versions of shared libraries. In any case, this won't be an issue for avrdude going forward since we're moving to static linking! 🎉

[dl8dtl]

Please don't take this "issue" as a "complaint".

That wasn't related to you but to the comment it were "unusable".

After all, this is a tool for programmers, not for the average computer user. So I assumed a programmer knows what a DLL is, and how to install it … but I accept I overestimated the concept of a shared library which apparently (except maybe for the system libraries) isn't so widespread on Windows as I know it from the Unix world. That's why I didn't even have the idea I should consider static linkage (which would have been possible as well in my MinGW cross-compilation environment), or shipping the DLLs along with the binary. I'm just not used to that. :)

(And btw., Unix shared lib version numbers aren't just a part of the filename. Notice they follow the .so filename suffix. They are really part of the concept.)

[cinderblock]

I don't think "unusable" is an unreasonable statement. Out of the box, the 6.4 binaries for Windows didn't match what users expected: that it just works.

People working with AVRs have no reason to know what a DLL is. There is barely a reason to know what a static library is. Granted most people working with AVRs are probably using Arduino which handles all of this complexity...

In any case, what you might think is obvious, others may reasonably have never seen. So unless it's clearly documented, expect someone to get it wrong. Even if it is clearly documented, people will get it wrong. It's only through repetition of common patterns and trying things that we learn anyway.

One final point to consider, there are some legal issues with redistributing others' DLLs. Of course, some DLLs' licenses come with explicit redistribution clauses, but that can't be assumed for all. However, if there are external dependencies on something that you can't (or won't) redistribute, it's reasonable for a user to expect included instructions on how to get, install, and link to those dependencies.

[dl8dtl]

One final point to consider, there are some legal issues with redistributing others' DDLs.

If there are, there are at least the same (if not more, in case of GPL rather than LGPL) issues with statically linking these libraries.

[mcuee]

The current official avrdude-7.0 Windows binary is using static linking, so that probably sorts out the issue for some people.

For me, I have totally differnet opinion and I prefer dynamic linking -- so that user can drop a new DLL if there are bugs with libusb-0.1, libusb-1.0, hidapi and libftdi.

Ref:

• Dynamic link to dependency libraries  #955

I actually have the MSYS2 binary here with static/dynamic linking for those who find issues with the official Windows binary.
https://github.com/mcuee/avrdude/releases/tag/v7.0

[mcuee]

How do you "install" something without an installer on Windows? There isn't a standard solution as far as I know. IMHO, If HIDAPI isn't mature enough to provide an installer (or at least prescribe where its dll goes), it's not mature enough to be depended on in the Windows ecosystem.

For your info, both libusb and hidapi do not provide an installer for Windows, because it is just a library.

For libusb-win32 and libusbk, we do provide an installer, because both projects have two components -- kernel driver and the library