bugAVR C Runtime Library - Bugs: bug #44574, Place device-specific libraries in...


You are not allowed to post comments on this tracker with your current authentication level.

bug #44574: Place device-specific libraries in their multilib directory.

Submitter:  Georg-Johann Lay <gjlayde>
Submitted:  Wed 18 Mar 2015 07:10:31 PM UTC
Category:  Library Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build system
Status:  Fixed Assigned to:  pitchumani
Percent Complete:  0% Open/Closed:  Open
Release:  1.8.0 Fixed Release:  None

Wed 15 Apr 2015 10:00:21 AM UTC, comment #2: 
Pitchumani <pitchumani>
Group Member
Mon 13 Apr 2015 12:47:36 PM UTC, comment #1: 

Attached patch to changes the startup object and device specific libraries name.
Also place them into multilib (architecture) location.
Startup object file name: crt<device>.o
Device specific lib name: lib<device>.a

Old startup object file name (e.g. crtm1280.o) is not removed from the device list yet.
This may be required when we make avr-libc compile-able with older gcc version.


2015-04-13  Pitchumani Sivanupandi <pitchumani.s@atmel.com>

        bug #44574: Place device-specific libraries in their multilib directory.
        * configure.ac (AC_CONFIG_FILES): Replace dev directory with architecture
        directory where device specific lib (lib<device>.a) and startup object
        file (crt<device>.o) to be installed.
        * devtools/Devices.am (avr_LIBRARIES): Change device library name to
        * devtools/gen-avr-lib-tree.sh (AVR12_DEV_INFO): Remove tiny stack devices
        as they are part of AVR12TS_DEV_INFO.
        (AVR25_DEV_INFO): Ditto.
        Change startup object file name to crt<device>.o and install location to
        multilib (architecture) directory.

(file #33665)

Pitchumani <pitchumani>
Group Member
Wed 18 Mar 2015 07:10:31 PM UTC, original submission:  

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.

Georg-Johann Lay <gjlayde>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #33665:  move-crt-lib-to-multilib-location.patch added by pitchumani (23KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pitchumani (Updated the item)
  • -email is unavailable- added by gjlayde (Submitted the item)

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-15 pitchumani StatusReady For Test Fixed
    2015-04-13 pitchumani Attached File- Added move-crt-lib-to-multilib-location.patch, #33665
        StatusNone Ready For Test
    2015-04-10 pitchumani Assigned toNone pitchumani

    Back to the top

    Powered by Savane 3.13-04b1.
    Corresponding source code