Libraries order inconsistant when changing configuration from Release to Debug

[lpcware]

Content originally posted in LPCWare by Xevel on Sat Mar 07 18:17:43 MST 2015
Hi,

I'm using LPCXpresso v7.6.0 [Build 321] [2015-01-26] on Windows 7 64bits Home Edition, up to date.
I started a workspace with the content of lpcopen_v2_00a_lpcxpresso_nxp_lpcxpresso_11c24.zip, then removed everything but the Chip and Board projects, then modified the board project, created some more libraries and applications.
I now have 3 libs (lpc_chip_11cxx_lib is as-is, and the other two rely on it, one being an adaptation of the Board project, and the other one completely new), and 4 applications, 3 that depend on all libraries and one that only depends on lpc_chip_11cxx_lib.

For all the applications, I ordered the libraries in Properties > C/C++ Build > Settings > Tool Settings > MCU Linker > Libraries as follows:
lib1
lib2
lpc_chip_11cxx_lib

Everywhere else where there are references to the library paths (library path, include path, ...), the order is the same.


Now I have the most disconcerting problem:
For only one of the application, (alphabetically, it's the second project in the workspace, but the first to rely on the 3 libs, the first project being the one that only relies on lpc_chip_11cxx_lib), when I change the configuration form Release to Debug, the chip library jumps at the top of the list in these lists (the exact name of the item that moves is in parenthesis at the end):

Properties > C/C++ Build > Settings > Tool Settings > MCU Compiler > Includes > Include Paths (-I) ("${workspace_loc:/lpc_chip_11cxx_lib}")
Properties > C/C++ Build > Settings > Tool Settings > MCU Assembler > General > Include Paths (-I) ("${workspace_loc:/lpc_chip_11cxx_lib}")
Properties > C/C++ Build > Settings > Tool Settings > MCU Linker > Libraries >Libraries (-l) (lpc_chip_11cxx_lib)
Properties > C/C++ Build > Settings > Tool Settings > MCU Linker > Libraries >Library search path (-L) ("${workspace_loc:/lpc_chip_11cxx_lib/Debug}")
Properties > C/C++ General > Paths and symbols > Includes > Additional Assembly Source Files > Include directories (/lpc_chip_11cxx_lib)
Properties > C/C++ General > Paths and symbols > Includes > Assembly > Include directories (/lpc_chip_11cxx_lib)
Properties > C/C++ General > Paths and symbols > Includes > GNU C > Include directories (/lpc_chip_11cxx_lib)
Properties > C/C++ General > Paths and symbols > Libraries (lpc_chip_11cxx_lib)
Properties > C/C++ General > Paths and symbols > Library Paths (/lpc_chip_11cxx_lib/Debug)


Note that "${workspace_loc:/lpc_chip_11cxx_lib/inc}" will NOT move in any of the "include directories" lists, but "${workspace_loc:/lpc_chip_11cxx_lib}" will happily jump at the top of its list.

Repeatability is 100% on this exact workspace content, I haven't tried on any other content because it's my first real LPCXpresso project.


Additional notes:

- Clearing all misc files does not change anything. I cleaned ALL files except .cproject, .project and source files (meaning I removed .metadata, all .settings, all Debug and Release folders), re-imported the projects, and it still happens.
- No impact if the order of the libs is changed in any way before changing the configuration from Debug to release then back to Debug.
- The other libs that rely on lpc_chip_11cxx_lib are affected too.
- The other applications are not affected.
- Only lpc_chip_11cxx_lib behaves that way. THe other libraries stay where I put them in the lists. Could it have something to do with the fact that everyone depends on lpc_chip_11cxx_lib (other libs and applications alike)?
- Release configuration keeps the order I set, whatever happens. Only Debug is affected by the change.
- As long as the configuration is not switched from Release to Debug, no problem.



This could easily be overlooked in many cases, but here it breaks the linking process of the affected application if lpc_chip_11cxx_lib is not the last in the list Properties > C/C++ Build > Settings > Tool Settings > MCU Linker > Libraries >Libraries (-l).

It might be something like the problem this person had : http://198.101.240.182/content/forum/libraries-search-path-chaos#comment-1142288

While it's not a deal-beaker, it IS annoying.

[lpcware]

Content originally posted in LPCWare by Xevel on Tue Mar 24 11:10:36 MST 2015
Hi,

Thank you, it seems that this workaround does the trick for me.

Just curious: will you try to figure out the root cause (the part your don't understand definitely looks like a bug to me), or will that be all for this matter?
In any case, I'm glad I can now switch between configurations freely and can remove the warning and temporary workaround from the doc of my project.

And by the way, how come there are multiple and non-synchronized places in the properties of a project that are named 'References' and that affect the project differently (Properties > Project references and Properties > C/C++ General > Paths and Symbols > References) ?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 23 16:42:13 MST 2015
The problem appears to be caused by a difference/conflict in the Paths and Symbols/References project settings.

To make the project build, always, I did the following to the app project:
- make sure the libraries are listed in the correct order on the Linker 'Libraries' setting for Debug and Release
- on Paths and Symbols/References:
-- ensure the Debug and Release configurations are the same (in your projects, the Debug lists the project dependencies, but the Release does not - this is why the Release config 'worked' but the Debug project did not)
-- ensure the lpc_chip project is listed FIRST (I don't understand why, but this seems to be critical)

Having made the changes, I can switch between Debug and Release, the .cproject file does not change and the projects build.

Let me know if this now works for you.

[lpcware]

Content originally posted in LPCWare by Xevel on Mon Mar 23 04:13:10 MST 2015
Great :)

---

Quote:
By the way, I presume from your comments that you are using GIT? Have you considered using the Eclipse eGIT plugin?

---

I do use GIT, however in the repository I manage the firmware (apps and libs), hardware, host software and documentation, as all of these need to stay in sync. It goes beyond what I would want to let this particular IDE (or any other) manage. But thanks for the tip, I might have a look next time.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 23 02:51:00 MST 2015
We've now managed to replicate similar behaviour when the projecta are not copied into the workspace on import and are now investigating further.

By the way, I presume from your comments that you are using GIT? Have you considered using the Eclipse eGIT plugin?

Regards
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by Xevel on Sun Mar 22 10:16:30 MST 2015
Strange.

The problem happens regardless of the folder (if I clone the repo again somewhere else it will behave the same, and using the folder you attached to a previous reply does the same).

Switching from debug to release changes the .cproject file, it's not a case of the program not being able to modify it.

Attached are the .cproject files:
- at the begining (1.cproject : Debug configuration when the libraries are ordered in the right way and it compiles)
- after changing to Release configuration (2.cproject). You can see that the file changed, the order of libraries changed as well as the nodes in the relevant listOptionValue XML beacon that now has an additional "srcPrefixMapping="" srcRootPath="" "
- after switching back to Debug, everything is back to the first state except for the library order.

Please check if these modifications happen on your side. To me, they all seem like they should not exist: I don't see why switching the current configuration should add or remove elements to the project description - but I'm new to that particular platform. In any other IDE I have used, the project descriptor holds the values for both cases, and another local file tells which one is the one currently in use, as well as all the parameters that change from one instance of the project to the other.


EDIT: I should add that the last step, to go back from 3 to 1, is to change the order of the libraries, which not only reorders the libraries but removes the "srcPrefixMapping="" srcRootPath="" " that appeared between 1 and 2, leaving a file exactly identical to 1 (diff doesn't return any differences)

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Sun Mar 22 03:58:01 MST 2015
Works perfectly for me every time. This is as I would expect.

Makes me wonder if you have a permissions problem on your workspace? We have 10's of thousands of LPCXpresso users and I don't recall anybody else reporting such a problem.

[lpcware]

Content originally posted in LPCWare by Xevel on Sun Mar 22 03:34:57 MST 2015

---

Quote:
Have you set the correct order for the libraries in the Debug build configuration? After setting the libraries correctly in both the Release and Debug configuration I see no such problems.

---

Yes, otherwise it would never compile.

The project you attached behaves in exactly the same way. Upon importing it the first time, the project is in Debug configuration and the libraries are already in the state with lpc_chip_11cxx_lib at the wrong place, and it does not compile (as explained in both my messages). I can change it in the Debug build configuration, it will compile. If I close LPCxpresso and re-open it, it will still compile. If I change the current configuration to Release, everything still compiles, and whenever I get back to Debug configuration, then the problem happens again. 100% of the time, with your files as with mine.

What happens if you change back to release then back to debug?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Sun Mar 22 01:26:06 MST 2015
Have you set the correct order for the libraries in the Debug build configuration? After setting the libraries correctly in both the Release and Debug configuration I see no such problems.

See screenshot attachment for how to change.

See zip file attachment for 'fixed' project

[lpcware]

Content originally posted in LPCWare by Xevel on Sat Mar 21 14:50:43 MST 2015
Hi,

Sorry for the delay.

Here is an example. It is a stripped down version of the workspace I used. It only has the app (app), the slightly customized board file (my_board), another lib (lib2) and the chip project (lpc_chip_11cxx_lib).
Lib2 and app have been reduced to their minimal expression but the effect can still be seen, at least on my computer.

Here is the exact steps I take to get from these files to the problem (100% repeatable on my computer). Version of LPCxpresso is still LPCXpresso v7.6.0 [Build 321] [2015-01-26], registered for free.

- Open LPCxpresso
- File > Switch Workspace > Other
- browse to the "TestWorkspace" directory and use it as workspace
- "File > Import..."
"General > Existing Projects into Workspace"  then click Next
Select root directory : browse to "TestWorkspace", which should be selected automatically, then OK
"Finish"
- Select all projects in the Project Explorer, Right click > Build Configurations > Set Active > Release
- Ctrl+B (everything compiles OK, two warning about an "inc" folder missing)
- Select all projects in the Project Explorer, Right clic > Build Configurations > Set Active > Debug
- Ctrl+B

It does not finish, these errors:

Building target: app.axf
Invoking: MCU Linker
arm-none-eabi-gcc -nostdlib -L"C:\Users\Xevel\Desktop\TestWorkspace\lpc_chip_11cxx_lib\Debug" -L"C:\Users\Xevel\Desktop\TestWorkspace\lib2\Debug" -L"C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug" -Xlinker -Map="app.map" -Xlinker --gc-sections -mcpu=cortex-m0 -mthumb -T "app_Debug.ld" -o "app.axf"  ./src/app.o ./src/cr_startup_lpc11xx.o ./src/crp.o ./src/sysinit.o   -llpc_chip_11cxx_lib -llib2 -lmy_board
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug\libmy_board.a(board.o): In function `Board_Init':
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/board.c:163: undefined reference to `Chip_TIMER_Init'
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/board.c:165: undefined reference to `Chip_TIMER_Reset'
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/board.c:169: undefined reference to `Chip_GPIO_Init'
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug\libmy_board.a(board_sysinit.o): In function `SystemSetupClocking':
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/board_sysinit.c:81: undefined reference to `Chip_SYSCTL_PowerDown'
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/board_sysinit.c:90: undefined reference to `Chip_SYSCTL_PowerUp'
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug\libmy_board.a(i2c.o): In function `Board_I2c_Init':
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/i2c.c:25: undefined reference to `Chip_I2C_Init'
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/i2c.c:26: undefined reference to `Chip_I2C_SetClockRate'
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/i2c.c:29: undefined reference to `Chip_I2C_SetMasterEventHandler'
C:\Users\Xevel\Desktop\TestWorkspace\my_board\Debug/../src/i2c.c:31: undefined reference to `Chip_I2C_EventHandlerPolling'
collect2.exe: error: ld returned 1 exit status
make: *** [app.axf] Error 1

- on the "app" project, Right click > Properties > C/C++ Build > Settings > Tool Settings > MCU Linker > Libraries >Libraries (-l) :  with the arrows, move lpc_chip_11cxx_lib down to the lowest position.
- Ctrl+B (everything compiles OK).


You can change whatever you want in the order of all the lists detailed in the first post, upon changing from Release to Debug, the order will be changed as previously explained, each time.


There, I hope if will behave exactly in the same way on your computers, and that you will be able to fix it. I would be very annoyed if I was the only one with this problem...

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 09 00:18:28 MST 2015
Can you provide a project that demonstrates this problem? We do not see this on any of our projects and so we would like to try to understand what is happening.