The current naming scheme for device-specific libraries

dev/<DEVICE>/libdev.a

bears the problem that it won't work if the install path contains spaces (as not uncommon under MS windows).

This is actually not an avr-libc problem but a problem with avr-gcc.  However, the new device-specific spec files have very limited means to handle paths containing spaces.

Wrapping the path in a space-escaping spec function does not work because that would require more than one level of escaping (which is not possible because the escape character would become a part of the path name).

One approach to make avr-gcc 5.0 + avr-libc work with paths containing spaces is renaming the device library to

lib<DEVICE>.a

and installing it in its multilib directory, i.e. in the multilib subdirectory as reported by

$ avr-gcc -mmcu=<DEVICE> [options] -print-multi-directory

For devices not natively supported by avr-gcc, avr-libc would have to know the correct multilib subdir.

Rationale is that multilib subdirs are common library search paths.  Hence the device library could then be specified as

-l<DEVICE>

and thus without explicit absolute path which works as expected.