[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] [bug #44574] Place device-specific libraries in their mul

From: Georg-Johann Lay
Subject: [avr-libc-dev] [bug #44574] Place device-specific libraries in their multilib directory.
Date: Wed, 18 Mar 2015 19:10:32 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv: Gecko/20110319 Firefox/3.5.18


                 Summary: Place device-specific libraries in their multilib
                 Project: AVR C Runtime Library
            Submitted by: gjlayde
            Submitted on: Mi 18 Mär 2015 19:10:31 GMT
                Category: Library
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Build system
                  Status: None
        Percent Complete: 0%
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.8.0
           Fixed Release: None



The current naming scheme for device-specific libraries


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


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


and thus without explicit absolute path which works as expected.


Reply to this item at:


  Nachricht gesendet von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]