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

 
 

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

Submitted by:  Georg-Johann Lay <gjlayde>
Submitted on:  Wed 18 Mar 2015 07:10:31 PM UTC  
 
Category: LibrarySeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build system
Status: FixedPercent Complete: 0%
Assigned to: Pitchumani <pitchumani>Open/Closed: Open
Release: 1.8.0Fixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 15 Apr 2015 10:00:21 AM UTC, comment #2:

Committed.
http://svn.savannah.nongnu.org/viewvc?view=rev&root=avr-libc&revision=2474

Pitchumani <pitchumani>
Project MemberIn charge of this item.
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.

ChangeLog

(file #33665)

Pitchumani <pitchumani>
Project MemberIn charge of this item.
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
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.)

Attach File(s):
   
   
Comment:
   

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
  • -unavailable- added by pitchumani (Updated the item)
  • -unavailable- added by gjlayde (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 15 Apr 2015 10:00:21 AM UTCpitchumaniStatusReady For Test=>Fixed
    Mon 13 Apr 2015 12:47:36 PM UTCpitchumaniAttached File-=>Added move-crt-lib-to-multilib-location.patch, #33665
      StatusNone=>Ready For Test
    Fri 10 Apr 2015 09:14:38 AM UTCpitchumaniAssigned toNone=>pitchumani

    Back to the top


    Powered by Savane 3.1-cleanup1