KDS Static Library Project - Another Bug Report - Need Fix

[eli_hughes]

Another issue with KDS V1.1.0 and a static library project.  (Started here KDS Static Library Project - Bug Report +Fix for future versions)

When the archiver is invoked,   It is not passing the correct path of the object files to the archiver.

Here is the example:

I am building CMSIS DSP 3.2.  The compile phase runs correctly.    All of the object files are stored in “./Debug/Sources/DSP_Lib/Source/…….”

So,  for a C file that is located in

“.Sources/DSP_Lib/Source/FilteringFunctions/armcorreclate_fast_q15.c”

The Object File will end up here:

“./Debug/Sources/DSP_Lib/Source/FilteringFunctions/armcorreclate_fast_q15.o”

“Debug” is the current eclipse build configuration.

Here is the issue. When the archiver is invoked it is passing the path to the source file, not the object file: (I cutout most object file paths for clarity)

make all

'Building target: libCMSIS_DSP_3.2.a'

'Invoking: Cross ARM GNU Archiver'

arm-none-eabi-ar -r  "libCMSIS_DSP_3.2.a" ./Sources/DSP_Lib/Source/TransformFunctions/arm_bitreversal.o./Sources/DSP_Lib/Source/BasicMathFunctions/arm_sub_q7.o ……………………………..

arm-none-eabi-ar: creating libCMSIS_DSP_3.2.a

arm-none-eabi-ar: ./Sources/DSP_Lib/Source/FilteringFunctions/armcorrelate_fast_q15.o: No such file or directory

make: *** [libCMSIS_DSP_3.2.a] Error 1

Notice that it is passing the path “./Sources/DSP_Lib/Source…..”    not “./Debug/Sources/DSP_Lib/Sources….”

I am not sure how to fix the setting that generates makefile.  

I have attached the project to this message.

Original Attachment has been moved to: CMSIS_DSP_3.2.zip

[auralcircuitry · Accepted solution]

For anyone else coming to this thread looking for a solution, this post outlines a very helpful solution which replaces the shell with something that accepts longer arguments than the Windows default.

This fixed the issue for me:

Solving the 8192 Character Command Line Limit on Windows | MCU on Eclipse

My hope is that Freescale can incorporate a similar solution into KDS directly.

[martynhunt]

Hi Eli,

The Windows command line length limitation can be avoided by bundling your input files into a single arguments file. I have edited the library project to include an arguments file. The arguments file is included like this:

Unfortunately I have not yet been able to add 'clean' support, so you must perform a manual clean by deleting the "Debug" or "Release" folder manually.

Please let me know if this method works for you, and I will keep you posted if I find a way to include 'clean' support.

Best regards,

Martyn

[danielkraemer]

Hi Martyn,

I'm having the same problem that Maurice describes and also looking forward for a solution using the CW aproach,

where the arguments to the linker are passed through a file.

Is there a plan on implemment this solution any time soon?

Thanks,

Daniel

[BlackNight]

Daniel,

The CodeWarrior approach was a very specific solution, and only for CodeWarrior.

I have filed a feature request on that topic. That solution is pretty much in the hands of the open source community and development. However, it is seen as a Windows problem, and most of the community workers are not using Windows, therefore that issue has a lower priority for them.

With this, at least until the foreseeable future, I would recommend that if you have that problem.

a) use relative paths in your project (the toolchain uses the (debug) output folder as current directory, so use ..\src instead of c:\myprojects\otherdirectory\ProjectA\Sources or similar for compiler paths/etc

b) Build one or multiple libraries you can link to your main application.

I hope this helps,

Erich

[eli_hughes]

Erich:

Thank you for the clarification.     I understand that there are many other options,   my point is that KDS is being sold by sales guys, etc as a replacement to Codewarrior.    There is a disconnect between legal statements on the website and how it is actually being market when you talk to people on the ground.

I understand there are growing pains but nowhere can I find the Freescale website a good comparison of the two.   I found one on your personal website (which is a great resource BTW) but it would be nice coming directly from Freescale.      For example,  know ahead of time about the build system limitations and debugging limitations is a nice thing (i.e. no visualization of peripherals, etc).

This really should be on the Freescale KDS Site (your article):

Comparing CodeWarrior with Kinetis Design Studio | Javalobby

I know at last year at FTF there was a lot of grumbing about Kinetis Build Tools switch over so there must be some interesting politics going on behind the seen.

Anyway,  I know KDS will mature.   Don't take any of this a too negatively.  I really like Kinetis Series and hope all this stuff gets fixed.

[danielkraemer]

Hi Erich,

I understand that it is a Windows issue and it will take time to implemment a native solution.

I have tried to shorten the path to the object files using relative paths as you suggested.

It worked for a while, but my project is still growing as my team is still adding more files and folders due to different modules and we reached the 8191 character limit again.

To avoid that problem, we choose to try the workaround pointed by Martyn, it's not yet automated, but it allows us to continue developing the application:

1. In Debug folder, created a file "ProjectName.args"

2. Copy object files paths into "ProjectName.args" ; for this, in Debug folder we looked into subdir.mk files and retreived the information under the variable OBJS.

3. Inside "ProjectName.args", set an object file path per line, and be sure to put the name between " " (ex.  "./Sources/main.o" )

4. In Project "Properties"/"C/C++ Build"/"Settings" ->  "Tool Settings Tab" -> "Cross ARM C++ Linker":

  - We had to modify the command line pattern: changed the argument ${INPUTS} to -> @"ProjectName.args"

As I said, this is just a "quick" workaround to turn the setup operational again, the downside is that it's not automated, so care must be taken when a file is added or deleted !!

I hope this information is useful to someone.

PS: By the way Erich, congratulations for your blog MCU on Eclipse | Everything on Eclipse, Microcontrollers and Software , it's a great place for learning =) .

[larrykoos]

Daniel,

Here is a workaround that automates the process you've described:

First, create a textfile called makefile.defs in the project's root directory. This file is referenced in the autogenerated makefile in an include statement as shown and is provided for the developer to influence an auto-generated make.

.

.

.

ifneq ($(strip $(S_UPPER_DEPS)),)

-include $(S_UPPER_DEPS)

endif

endif

-include ../makefile.defs

# Add inputs and outputs from these tool invocations to the build variables

# All Target

.

.

.

Use this file, makefile.defs, to copy all the compiled object files and libraries into a file which we called ObjectList. The makefile script we used is:

$(shell rm ObjectList)

$(foreach obj, $(OBJS), $(shell echo $(obj) >> ObjectList))

$(shell echo $(USER_OBJS) >> ObjectList)

There is probably a more efficient script than this but I'm not a script wiz.

Finally, edit the project linker settings' Command Line Pattern to remove the reference to $(INPUTS) and replace it with @ObjectList

Hope this helps

[dave408]

Hi Daniel, thank you for sharing your solution.  Assuming that my problem is related (my linker gives me errors, indicating a corrupted file path in the linker args around position 8210), I have tried what you have proposed, but now I end up with this error:

c:/freescale/kds_1.1.1/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.0/../../../../arm-none-eabi/bin/ld.exe: cannot find entry symbol __boot

I've looked online, and it sounds like I might have to write a custom linker script, but as I am new to this sort of development environment (sorry, I come from Visual Studio), I'm not sure how to proceed.  I'll keep digging for info, but if you have any suggestions, I'd appreciate it if you would share them.

Perhaps I should switch over to Linux temporarily just to see what the difference is.  :smileyhappy:  This Windows issue is sure a bummer.

[eli_hughes]

I found that the path of least resistance was to get VMware player (Free) and a copy of Ubuntu.    This way you can run it on your windows machine.   The VM + Eclipse is a bit laggy/slow but it is usable.     If you use a 64-bit version of Ubuntu you will need to install the support libraries.  (Some threads about this on the Forum).  VMware allows you to setup a nice shared drive so you can see you files from the windows side.

It is a bit of a pain, but it allows you to workaround the issue.

[dave408]

Umm... dumb question -- how do you find KDS once you've installed it under ubuntu?  I installed it, then install MQX for KSDK.  The latter was easy to locate since it prompted me for the location, but I don't have any idea what the executable is called so I can't find it!  :smileyblush:

[dave408]

Ah nm... I found the info in the thread that talks about compatibility with 64 bit ubuntu -- /opt/Freescale/KDS_1.1.1/eclipse/kinetis-design-studio.  :smileylaugh:

[dave408]

Yes, that is exactly what I would do.  Probably would just run Ubuntu 32 bit since I'd only be able to allocate 2GB of RAM anyway.  Thanks for the warning on the 64 bit version!  Oh, except that I would typically use VirtualBox, which is also free and seems to have pretty good USB support now.  Do you know if the SEGGER firmware / driver for mbed works okay in VMWare?

[eli_hughes]

Eric:

It sounds from your description that KDS is open source project driven by volunteers, not a Freescale sponsor tool with paid Freescale developers? If so, that is a little scary given that the verbage on the Freescale Website says it will be the future for Kinetis.   

If the developers really only develop  and test for the Linux side of things,  it should more clearly advertized so people don't spent a lot of time trying to use a tool that won't be actively developed on platforms that are more common in the business world.  (not saying Linux is bad,   I have observed that a majority of commercial product development uses windows based tools  .... Keil, IAR, etc)

It would save new developers a lot of time not evening going down the KDS path (porting from Codewarrior) and look for options that are designed to also work on Windows.

[BlackNight]

Eli,

KDS with the with the exception of Processor Expert is built on open source (gcc, gdb, Eclipse itself, Eclipse plugins, ...), and this is maintained by the open source community. Nothing scary about that, unless you find any product scary which uses open source tools. KDS is built on open source, and does not divert from it. And a lot of that open source is indeed developed by volunteers for which we all should be grateful for. What Freescale adds to it are the Freescale specific parts (Processor Expert, the new project wizard, the packaging and testing). But Freescale does not develop/changes Eclipse: that's owned by the community. Dito for gcc and gdb or the build system. Keep in mind that KDS is a zero dollar tool, free of charge, and not intended to compete with the commerical tools like IAR and Keil. I hope that makes sense.

Erich

[eli_hughes]

Eric:

OK, I think our wordings are a bit different.   Let me reword my question.      Is KDS *as a package* maintained by Freescale,  or is an open source effort too?   If it is the latter, can we access to the repositories?

I am completely understand (and am OK with) that the underlying tools (GCC, Eclipse) are open source tools.    But is the overall effort of stitching them together to make KDS a Freescale supported effort?

I am using several other toolchains for other vendors (LPCXpresso for NXP devices,  Xilinx SDK)  that are doing the exact same thing as KDS (stitching together Ecpilse + GCC, etc).   In the LPCXpresso case though,    the overall tool is supported by NXP.  I can get a hold of NXP (and have on several occasions) about a bug and they fix.   Oftentimes it is something about the integration of the tools.    They have never stated that it won't be fixed as GCC, eclipse, et al   won't fix the issue.   they simply make it work in the overall package.

That being said,   I know this particular issue must be solvable.    I have brought the entire CMSIS package into other Eclipse based tools and it compiled under windows.   This issue has simply never come up.    And... If Codewarrior solved it, why not just bring in that solution?   If it is because the goal is to leave the underlying tools as "stock/vanilla", then there is some disconnect between what a Freescale Customer wants and the development strategy.

Keep in mind the narrative being pushed by Freescale.   "Codewarrior is no longer supported for Kinetis,  Use KDS."     Well,   people are using it and it can't handle projects with many files (or long file names) .   This is a  core piece of functionality.         It doesn't matter what the implementation issue is,    from the user perspective the new replacement tool is missing features that the last tool had.     Given that the last tool is going away and the new tool is being advertised as the replacement what is one to do?   I understand that KDS is free of charge BUT if it is to be the Freescale supplied/supported tool, it needs to be developed as something comparable to the last tool.

And if Freescale won't do that, that is OK.    They just need to put some warning labels that this tool (not the pieces like GCC,  but the over all integration) is not maintained to be a comprehensive tool like Codewarrior.   That will at least get people in the mindset that they need to go to Keil or IAR to get something comprehensive.  Right now it *IS* being sold by everyone in the Freescale chain as "the comprehensive, Freescale Supplied tool for Kinetis Development".     The message needs to get fixed or the KDS development approach needs fixed.

[BlackNight]

Yes, KDS as a package is provided and maintained by Freescale. And on www.freescale.com/kds you can dowload the source file package for it. And the the underlying packages are stock/plain vanilla ones, as you stated.

For the support model, www.freescale.com/kds says:

     "The Kinetis Design Studio is offered for free, and support for it is provided through the Freescale Kinetis Design Studio Community Forum."

Kinetis Design Studio is *not* CodeWarrior which had a lot of custom, special and advanced extensions. Kinetis design studio is packaged from stock open source components with the addition of Processor Expert, integration with the Kinetis SDK and a wizard to create projects. It is a completely free of charge product, it is not a commercial product like CodeWarrior is. If KDS does not fit your needs, then there are plenty of choices liste on IDEs for Kinetis MCUs|Freescale

I hope this helps,

Erich

[mauricelauze]

Very interesting discussion...

I would be interested to know the ratio between windows and linux developpers...

For myself, I know very few people who professionnaly work in the embedded developpment under linux.

But I may be wrong...

Anyway Erich, you say that the job for Freescale is in part to test the tools given to customers.

And some customers are using Windows, so I have to say that the tools are not sufficiently tested !

My Freescale distributor said to me to go under KDS as I will have to use a new Kinetis device and I am a new user of Kinetis...

My feelings is that KDS needs more testing under Windows platform and more documentation especially for Processor Expert that is not finished as the Code Warrior version.

It is a Freescale job to do that, not a customer volunteer based task...

Maurice

[mauricelauze]

Hi Martin,

I am facing the same issue due to the limitation of the command line lenght under Windows when the linker is called...

I've found a temporary solution using a shorter path for some librairies...

Before that, I've tried your solution without any success. I didn't find a way to pass some librairies to the linker using a file.

I am currently in the beginning process of my project, with few files, and I am surprised to face such a problem !

Passing a file to the linker was used in CW10.4 and it seems necessary to do the same in KDS.

When will it be available ?

Thanks,

Maurice

[eli_hughes]

Erich:

Reducing the number of files did work.   I had to move the project to the root directory to get a partial library.  

As a data point,  I was able to compile the full CMSIS DSP library under codewarrior (10.5) without issue.   In fact,  the path to the project is quite long. 

I am not sure who developed KDS (it appears to be a 3rd party party tool) but hopefully they can look at how Codewarrior manages builds and take that approach.   Its  build system  seems to be more robust  in this case.

Martyn:

Thanks for the TIp.

At this point I will stick with Codewarrior until there is fix in this tool so I can continue work    I have several libraries that have quite a few files and it will be a mess trying to hack them into the KDS build system. 

[BlackNight]

Hi Eli,

It is passing the correct path to the object file. The current folder for the 'ar' program is the debug folder, and inside the debug folder there are the 'source' folders replicated (with the object files). The following picture illustrates this:

I think what you are running into is a Windows limitation: your command line length to 'ar' is probably larger than 8192 characters, and then it fails with that message.

Just for a test, try to reduce the number of files/objects to archive, and I think it will work.

So if this is indeed the case: shorten the path length, or make two or more libraries.

I hope this helps,

Erich