This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linker warning: "no matching section"

Hi,

I'm building big project consisting of a number of projects, which are all compiled as libraries and then linked into the main project. My setup is as follows:

CCS 5.1

Code Generation Tools 7.3.2

DSP/BIOS 5.41

Target: C6418 DSP

Everything compiles fine, but I'm getting a very cryptic linker warning during the linking process for the following section in my own linker command file:

SECTIONS
{
   .s4538_ext_data:  {
      
        -l=rm_s4538_arcs.lib (.bss)
        -l=rm_s4538_arcs.lib (.data)
        -l=rm_s4538_arcs.lib (.far)
        -l=rm_s4538_arcs.lib (.const)
          
    } > SDRAM_DATA

}

The warning is simply "no matching section" for all the lines starting with "-l". What I'm trying to achieve is to take those sections of the compiled library and place it in our external SDRAM, since we want to use the internal RAM for more critical stuff. I have included the particular library in Build Options -> C6000 Linker -> File Search Path, which makes the syntax valid as described in C6000 Assembly Language Tools v7.3 User Guide (SPRU186V.pdf). I tried the variations on the syntax as mention in the user guide, but it made no difference. I also had a look in the resulting MAP file and th .s4538_ext_data section is definitely not created. Can someone please explain to me why I'm getting this warning and what I can do to get rid of it?

On a related note, what is the proper CCS 5.1 way of including other dependent projects into the main project?

Thanks in advance!

Regards

 Reinier

  • Reinier,

    There are a couple of things you could check first.

    The syntax "-l=" when specifying library is not supported in most versions of the codegen tools. This was a bug in the documentation. I'm not sure if this syntax is now supported in the latest 7.3.2, but if this were the issue I would've expected a syntax error reported by the linker. In any case, please try the syntax without the "=" sign in the allocation as described here.
    http://processors.wiki.ti.com/index.php/C6000_Assembly_Language_Tools_Errata

    The other thing to check is if a previous allocation in your linker command file is already allocating all of those input sections to a different memory region. Please see this related thread in case your situation is similar.

    Reinier Coetzer said:

    On a related note, what is the proper CCS 5.1 way of including other dependent projects into the main project?

    In CCS5.1, if you go into Project Properties->CCS Build->Dependencies tab, you can specify dependent projects there. For example, you may have a project that creates a archive library as output and that could be added as a dependent project to another project.

  • Hi AartiG,

    Thank you for your response.

    I actually already tried the syntax you suggested, but it made no difference. I have a feeling this is not a syntax related warning. My own linker command file is really simple and its definitely not already allocated there. However, DSP/BIOS obviously generates a linker command file and it might be somehow allocated there, but this is of course re-generated with each build and I'm not sure how I can control this from the *.tcf script. I did notice that some of the objects from the particular library were already allocated in the map file, but there is not explicit reference to the library itself or the section I defined in my own linker command file.

    In terms of the project dependencies, I'm currently doing following: in the dependencies tab I select all the dependent projects in the workspace and I also link the main directories of the dependent projects to the project. In this way the main project compiles and links successfully (but still with the above mentioned linker warning). Is there a problem with this approach? A very annoying thing I've noticed, is the CCS 5.1 would throw the dependencies away with certain events, which I am unable to pinpoint at the moment. Consequently from time to time I have to go to the Dependencies Tab and again add all the dependent projects. I'm not sure if this is a known issue/bug with CCS 5.1.

    Any further suggestions on these problems?

    Thanks!

  • Ok, I missed the point earlier that you were using BIOS as well as adding a custom linker command file. What is happening here is that the BIOS generated linker command file is being passed to the linker first in the command line, hence the default allocations are being done as per this command file, and since those sections are now already allocated by the time it gets to your custom file, there are no more matching sections.

    You can confirm this by looking at the link command in the CCS build console.If you see your custom linker command file being passed after the BIOS cfg.cmd file that would confirm it. If so, you can control this order by going to Project Properties->CCS Buils->Link order tab. Add both linker command files and then make sure your custom cmd comes first.

    Let us know if this helps resolve the issue.

  • AartiG,

    I have also tried this, but it again dit not make any difference. From the console it still appears as though the generated linker command file is called first. I'm not sure why the link order is being completely ignored. Is there maybe something else I can try?

    Do you perhaps have any other suggestions on the dependent projects being removed in CCS5.1? I noticed it happens in some cases when I cancel a build a in progress.

    Thanks again!

  • Reinier Coetzer said:
    From the console it still appears as though the generated linker command file is called first. I'm not sure why the link order is being completely ignored.

    That is strange. I tested it with a simple example and was able to change the link order as desired.

    Was this a CCSv4 project that you imported into v5? If so, I wonder if the migration is causing some of these issues. Can you confirm if you can get link order to work properly with some of the template example projects provided with CCSv5? That could help point to whether this is specific to your particular project or something else in your set up.

    Reinier Coetzer said:

    Do you perhaps have any other suggestions on the dependent projects being removed in CCS5.1? I noticed it happens in some cases when I cancel a build a in progress.

    I have not seen this happen and am not sure what could cause it unless there is a bug in the tool. I could try reproducing it by canceling a build, however if it is not consistently reproducible, even at your end, it is going to be difficult to analyze.

    Reinier Coetzer said:

     In terms of the project dependencies, I'm currently doing following: in the dependencies tab I select all the dependent projects in the workspace and I also link the main directories of the dependent projects to the project.

    I'm not sure I understand what you mean by the statement in bold, could you please elaborate?

    Typically, dependent projects are used for generating libraries which are then linked into the main project. In this case, the dependent projects can be added to the Dependencies tab of the main project, and the library names added to the main project's --library option.  The dependent projects also need to be imported into the workspace. Then when the main project is built, it will go off and build the dependent projects first (if needed) and then the main project. Is this what you are already doing?

  • Hi AartiG,

    Sorry for only responding now, but I first had to perform a few tests on my side.

    Yes, I did import the project from CCSv4 into v5. I noticed that the importing wizard did few a fishy things, so I decided to create all the individual projects again from scratch in CCSv5.1

    What I did was go to Project -> Properties -> C/C++ General -> Paths and Symbols. In the Source Location tab, I clicked on "Link Folder..." and linked the main folder on the actual file system of each dependent project. All of the dependent projects were already in the same workspace and I also added each of them on the Depdencies tab. When I did a full re-compile, everything compiled and linked successfully and I was able to run the project on the actual target and that also worked fine.

    However, when I tried it the way you described, i.e. make sure all the depdent projects are in the workspace,  add the depedent projects in the Dependencies tab and also add all of the resulting *.lib libraries with --library option (Properties -> CCS Build -> C6000 Linker -> File Search Path), it did not work at all. I got hundreds of 'unresolved symbol' linker errors. I'm not sure what the problem might be, but from the Wiki it may have something to do with C++ template instantiations (we use both normal C and C++ in the project). 

    Can you please help me solve this?

  • Reinier Coetzer said:
    However, when I tried it the way you described, i.e. make sure all the depdent projects are in the workspace,  add the depedent projects in the Dependencies tab and also add all of the resulting *.lib libraries with --library option (Properties -> CCS Build -> C6000 Linker -> File Search Path), it did not work at all.



    Did you actually open the dependent projects in the workspace? Did you see them getting built prior to the main project? Another option if you do not need the dependent project to build every time is to simply add the libraries to the main project and build the library project separately to generate the .libs (may need to only be done once or very infrequently if the files do not change much).

    It sounds like you now have a good working build if you add the source location via Project -> Properties -> C/C++ General -> Paths and Symbols. If you would like us to further research the problem with the other method, would you mind creating a new forum post for it, so we can keep these issues separate which makes tracking easier. We may need a simple test case to analyze further the reason for the linker "unresolved symbol" errors so I would appreciate it if you could create a new post and attach a reproducible test case there.

    Thanks!

  • AartiG,

    Yes, all of the dependent projects were open in the workspace and they were also getting built prior to the main project.

    I actually got the project to compile and link with both methods described so far. However, with the method you proposed, the issue was indeed template instantiations and for the project to link successfully I had to explicitly instantiate the templates. Now the new problem is that linking takes forever with *any* change made to the main project, which will definitely make development very tedious. I already link with the --no_sym_merge option, so I can't understand why linking takes so long.

    With the other approach I tried, i.e. link all the source directories to the project, it was not necessary to explicitly instantiate any templates and linking would also take much shorter. The linked source directories actually do not even contain any source files, since all the source files of each project are only linked to the project. The linked source directories only contain the project files, the files generated for its configuration, the object files and the resulting *.lib files.

    I do not really understand what's happening here! Do you perhaps have some insight?

    What would be an appropriate topic for a new thread for this issue? I fear I will not be able to produce a test case, mainly due to IP issues.

    Thanks again!

  • Reinier,

    I would suggest studying the build command line (check the full output of the CCS build console) in the two cases to see how the builds are different. I suspect the way the object files and libraries are being linked is different in the two cases. Also since you mention template instantiations, this wiki page might be helpful in explaining why/when you could see linker errors when using templates: http://processors.wiki.ti.com/index.php/C%2B%2B_Template_Instantiation_Issues

    This thread has deviated quite a bit from what it originally started with, so please open a new thread if you need further assistance with specific issues.

  • AartiG,

    Thank you for all your help. I think to conclude this thread, I believe the importing wizard in CCS5.1.0 did something fishy when I imported the project from CCS4.2, so I would suggest anyone having similar issues to rather try and build the project from scratch and not to trust the importing wizard!


    Reinier

  • Reinier,

    Thanks for the update. I am glad you are able to move forward. We are continually working on improving the import wizard but in some cases, depending on the complexity of the project, the import wizard is not perfect. In such cases, as you inferred it is better to create a new project in CCSv5.