Purpose of libc.a

Do we include the source code for libc.a with the code gen tools?  I'm curious how it actually works.  Perhaps the same concept could be utilized in other TI libraries.  That might be a big help in eliminating some of the errors that pop up from choosing the wrong library.  For example, I wonder if it could actually allow multiple libraries to be linked in.  This is one of the things that RTSC is supposed to bring as a powerful feature but it looks like you guys have done it without needing RTSC.

Brad Griffis said:

Do we include the source code for libc.a with the code gen tools?  I'm curious how it actually works.  Perhaps the same concept could be utilized in other TI libraries.  That might be a big help in eliminating some of the errors that pop up from choosing the wrong library.  For example, I wonder if it could actually allow multiple libraries to be linked in.  This is one of the things that RTSC is supposed to bring as a powerful feature but it looks like you guys have done it without needing RTSC.

There is no source code for libc.a; it is generated from other libraries.  It relies on build attribute checking in the linker.  The documentation for libc.a has been sourced, and should be in the compiler user's guide.  Yes, this is intended to work with any set of otherwise-identical libraries which have distinct sets of build attributes.  The linker will only pick one library from each index file.  RTSC is not used to implement libc.a

Archaeologist said:

The documentation for libc.a has been sourced, and should be in the compiler user's guide.

I was looking in the linker guide since this seems to be a linker feature.  Seems odd to document the feature in the compiler guide but maybe that's because I don't really understand how this works still. 

Archaeologist said:

The linker will only pick one library from each index file.  RTSC is not used to implement libc.a

I'd like to understand how you do this, i.e. could I do the same thing for our dsplib?  The user would link dsplib.a and depending upon whether they were building for 67x, 67x+, or 674x they would end up getting a different library?  How do I go about doing that?  I know how to do it with RTSC, but I think RTSC can be overkill for some stuff and would rather use something simpler whenever possible.

Brad Griffis said:

'd like to understand how you do this, i.e. could I do the same thing for our dsplib?  The user would link dsplib.a and depending upon whether they were building for 67x, 67x+, or 674x they would end up getting a different library?  How do I go about doing that?  I know how to do it with RTSC, but I think RTSC can be overkill for some stuff and would rather use something simpler whenever possible.

Yes, this is intended to work with any set of otherwise-identical libraries which have distinct sets of build attributes.  Basically you just compile your library N ways with N different option sets (presumably varying by 67x, 674x, etc), place them in a directory, run libinfo6x and presto, you have a new index library.  This should be covered in the user's guide; has this not made it into the released version of the book yet?

Ah, thanks, now I see it.  I just didn't know what to look for.  Once I searched for "libinfo6x" in the latest assembly tools guide I found it.  Now it makes a lot more sense.  Very cool feature!  Perfect for something like dsplib.