Hi All,
FYI
I have just updated to DS2.1.1 and have already experience some problems.
For example
We’ve experienced some of these issues as well, including a project we’re referencing not being found (although it’s open in Dev Studio and in the same location it was before, with the files all there), and many compilation errors (hundreds in our case as well). Many of the errors are reporting things like standard ADL types like “u32” and “ascii” being undefined. Opening configurations->Manage got rid of the compilation errors (thanks to Terrence for the fix) but we still have a broken project reference.
Update:
After running into problems, I decided to revert to a previous version, but halfway through, the revert failed.
So, while looking for the previous version to download… I ran into the release note for 2.1.1 http://www.sierrawireless.com/Support/AirPrime/releasenotes/Developer_Studio_2_1_1.aspx, which mentions new project metadata etc, and the fact the once your project has been converted, it will no longer be compatible with the previous version of DS.
So, I created a new workspace, to give DS2.1.1 a “fair” chance, and imported my projects.
The projects all built correctly, with no errors.
However, when running the code, (Run As -> Open AT Target Application), sometimes the “Preparing the Target for Launch” window, says on screen, with a message “Check if Target is Running”, while my application is actually running.
I think that an program update from within DS should present the release notes before asking to update.
Hi Terence,
we’ve indeed modified project interdependencies management in 2.1.1
What’s the old behavior (DS <= 2.1.0)?
When declaring a reference between an application project (let’s call it app) and a library project (let’s call it lib), DS was automatically handling the things below:
What’s the new one (from 2.1.1)?
Eclipse CDT allows a library project to declare which settings it wants to export.
DS 2.1.1 is now using this mechanism to improve its compatibility with CDT projects handling.
The idea is that exported settings from lib project are automatically added to the app project as soon as the reference is declared.
The first step is to check what settings are exported in lib project. It can be verified in Project Properties > C/C++ General > Export settings
Exported settings can be:
Once settings are exported, they are added to the referencing project.
References are managed at two levels:
Global reference can be added in the Project properties > Reference page. When a reference is added here, references are automatically added for each build configuration.
Configurations references can be added/modified in the Project properties > C/C++ General > Path and symbols > References page. Once such a reference is set:
What do I need to do to build my projects again 2.1.1?
First of all, projects which don’t use references shouldn’t have issues when migrating to 2.1.1
When using references, there can be two cases:
Projects created with 2.1.0
Library projects created with 2.1.0 version have normally their exported settings defined correctly, except the itf include path export definition
To restore the build, you’ll need to export manually the itf path in all configuration (just click Add button, select the folder in the workspace, click “for all configuration”).
If it still doesn’t work, references may need to be refreshed: in the app project, just try to remove the global reference and to add it again.
Projects created with former versions (<2.1.0)
Projects created with these versions unfortunately don’t have any export settings automatically declared.
Here is a concrete example, for a project named “MyLib”, with two [Target]_ARM_EABI_GCC_Debug and [Target]_ARM_EABI_GCC_Release build configurations.
If it still doesn’t work, references may need to be refreshed: in the app project, just try to remove the global reference and to add it again.
Obviously, you can also completely create again the projects with 2.1.1…
Sorry for the long post, but complicated subjects require long explanations 
Please post if things are still unclear.
Hi daav,
Thanks for the lengthy explanation, I’m sure many will benefit from it.
I had fixed the library problem by setting the itf path in my app, and specifying the lib name.
I had an installation of DS2.1.0 on my laptop to compare with.
I have however, gone back to using DS2.1.0, as DS2.1.1, as I have seen some funnies with DS2.1.1 and don’t have the time to investigate further.
As soon as you have some spare time, please don’t hesitate to share here what’s going wrong for you.
We entered project reference settings as per Daav’s post above, It’s now finding the referenced project’s header files, but still not finding the library file. The error message is
c:/program files/sierra wireless/developer studio/tools/armeabigcc/4.4.1/bin/…/lib/gcc/arm-none-eabi/4.4.1/…/…/…/…/arm-none-eabi/bin/ld.exe: cannot find -lC:\Sierra\Workspace\ethernet_driver[Target]_ARM_EABI_GCC_Release\ethernet_driver.lib
The lib file is definitely there.
Now the earlier problem originally reported by Terrence has mysteriously returned, and we’re again seeing hundreds of errors, most of them reporting symbol xxx can not be resolved (see attachment). The previous fix of opening Configurations-> Manage, and not changing anything didn’t work this time (not entirely surprising, why should something like this fix it in the first place). Many of the unresolved symbols are ADL types like u8, u16, etc. so apparently there is a problem involving parsing of header files (any headers, both ours and adl headers)
Not sure if this information would be of any help, but at 1 point I noticed that all definitions as below were causing unresolved symbol errors:
typedef struct
{
…
} struct_t;
Followed by a declaration (in a different file)
struct_t struct_instance
Note the errors are not flagged by the familiar red x, but by a (new?) bug icon
So I changed one of them to
struct teststr
{
…
} ;
Followed by a declaration (in a different file)
teststr struct_instance;
And not only the error for this instance but all the other errors also went away! ???
(Only to return later)
I’m going to have to go back to 2.1.0 as well unfortunately, having spent 3 days so far chasing gremlins.
errors.zip (244 KB)
This looks suspicious to me, -lC:\Sierra\Workspace\ethernet_driver[Target]_ARM_EABI_GCC_Release\ethernet_driver.lib.
Commonly this is done as -LC:\Sierra\Workspace\ethernet_driver[Target]_ARM_EABI_GCC_Release -l ethernet_driver which will look for libethernet_driver.a. This seems to me like a mix of Windows (MinGW perhaps) and gcc. For eclipse this means you have to setup the path in one page, and the library in another.
Regarding include files, also make sure the directory is not marked as “exclude from build” or something the like. Eclipse will not pass the include directory to gcc if marked as such. Likewise, if headers from a closed project are included, eclipse will “help” you by removing the include directory.
That said, above won’t likely solve all your problems, so if you’re happy with the old version, just use that one.
edit: just reading daav his post, he spelled it out already.
Concerning -l option, nothing more to add to Jeroen’s post (lib path and name are defined on to separated pages, using the GCC convention).
Concerning lost ADL includes, your configuration may have became “broken” for any reason…
Fortunately, we’ve introduced mechanisms in 2.1.1 to help diagnostic (and fix) such kind of issues.
In DS preferences, go to C/C++ > Property Pages Settings > CDT Utils property pages, and check the Display “External Settings” tab
From there, go to your Project Properties > C/C++ General > Paths and Symbols page
There should be a new “External Settings” tab displayed.
You have to make sure that the “Developer Studio external settings provider” entry is checked for each of your build configurations.
This is the way used by DS to contribute to your project the include paths provided by the packages selected in the Open AT Application property page.
PS: FYI, “bugs” markers come from new Eclipse CDT integrated version (CDT 8 ), introducing a static code analyzer (aiming to report errors & warning even before launching the build).
Ok, but it seems to have “broken” in exactly the same manner as Terrence’s, which I would think should be cause for concern on Sierra’s part.
I’m not sure which two pages you’re referring to, if it’s the Libraries and Library Paths pages under C/C++ General->Paths and Symbols, the name and path were already defined on the respective pages.
After reverting to 2.1.0, we were having the same issue with the linker being unable to locate a library file. So obviously the project had been changed when it was opened in 2.1.1. After some experimenting we finally found a fix for the linker problem. The library entry under paths and symbols was listed as ${workspace_loc:/ethernet_driver/[Target]_ARM_EABI_GCC_Debug/ethernet_driver.lib}, by changing it to simply ethernet_driver the project now links without error.
Going back to our 2.1.1 installation, the fix works there as well.
It was indeed unchecked for one of the build configurations when we looked at it, however it seems odd that it would be checked for one configuration and not the other, also it’s odd that the problem would come and go the way we’ve seen it do.
This was indeed the setting which required to be set.
To summarize what’s said in my post above, when you have an “foo” library project, producing a “foo/[Target]_ARM_EABI_GCC_Debug/libfoo.a” archive file.
In the Export Setting page of the foo project, the Library entry will have to be set to “foo” only, and the Library path entry will have to be set to “foo/[Target]_ARM_EABI_GCC_Debug”
From there, as soon as an application project will depend on it, these settings will automatically be added to its linker settings.
This is a bug introduced in former DS releases (< 2.1.1). There shouldn’t be the issue anymore starting from 2.1.1 (I mean the checkbox won’t become again unchecked, but you have to fix it manually before).
I upgraded to DS2.1.1 last week and I find that I get lots of “Symbol XXXX could not be resolved” Semantic Errors in the Problems window when i open some of my source c files in DS. The program compiles fine however and this did not happen with the version of DS I was previously using.
I can remove the errors via Project->Properties->C/C++ General->Code Analysis and selecting “Use Project Settings” and Unchecking “Symbol is not Resolved”, “Method cannot be resolved”, and “Field cannot be resolved” under the “Syntax and Semantic Errors” section.
Note that the things in my code that seem to bring on this problem is having a define in the C file that conditionally defines extra items within an included include file and the c file references those extra items.
eg
Description Resource Path Location Type
Symbol ‘TST_StateStr’ could not be resolved tst.c /WFT_110_745/src line 273 Semantic Error
In tst.c:
#define TST_MODULE 1
#include “tst.h”
…
TST_StateStr[eTestState] //line 273
…
In tst.h:
#ifdef TST_MODULE
char *TST_StateStr[TST_STATE_MAX] =
{
“IDLE”,
…
};
#endif
I find that if i define TST_MODULE in tst.h the semantic errors disapear.
Note that the semantic errors do not always get reported for this sort of code as i created a hello world example with this sort of code and the semantic errors did not get reported.
DS 2.1.1 is based on an Eclipse CDT release which newly integrates a static code analyzer (“codan”; cf wiki.eclipse.org/CDT/User/NewIn8 … 28Codan.29)
We didn’t experienced problems with it, but maybe in some cases this code analysis is not perfectly accurate…
Otherwise, it should be an index refresh problem. You could give a try to refresh the index or the code analysis by trying the project right-click menu options: