• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 2566 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Segmentation fault when building ARM RTS lib

giuliano barbieri1
Prodigy 130 points
Other Parts Discussed in Thread: HALCOGEN

Hi,

I have a different problem trying to compile the Uartecho example project  I gat the error message :

warning: automatic library build: using library
   "C:/ti/ccsv5/tools/compiler/arm_5.1.1/lib/rtsv7A8_A_le_n_v3_eabi.lib" for
   the first time, so it must be built.  This may take a few minutes.
      0 [main] sh 168 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
C:/DOCUME~1/BARBIE~1.SEL/IMPOST~1/Temp/make3544-1.sh: line 1:   168 Segmentation fault      (core dumped) c:/ti/ccsv5/tools/compiler/arm_51~1.1/bin/armar -qa c:/docume~1/barbie~1.sel/impost~1/temp/ti2762~1/rtsv7a8_a_le_n_v3_eabi.lib *.obj
gmake.exe[1]: *** [library] Error 139
>> ERROR: mklib: gmake error during rtsv7A8_A_le_n_v3_eabi.lib build
error: cannot find file "rtsv7A8_A_le_n_v3_eabi.lib"


I don't understand whether there is an error in my computer or something else

Thanks

Giuliano

 

 

 

  • 0
    TI__Guru**** 232920 points

    Here is what is happening.  The linker discovers the RTS library rtsv7A8_A_le_n_v3_eabi.lib is not present, so it invokes mklib to build it.  This utility uses a combination of make, sh (a Unix like shell), and the archiver armar.  The sh command crashed.  You might be experiencing this problem.  A possible workaround is to use mklib to manually build that RTS library.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 232920 points

    I have devised another workaround to this problem.  I am highly confident it solves the problem.  However, since I am unable to exactly reproduce your problem, I cannot be certain.  I'd appreciate if you would try it and let me know how it goes.  If it works well, I will probably make a wiki article for this solution.

    The problem is that, when mklib (invoked by the linker) builds a new RTS library, it invokes sh and gmake commands from the user's system path, and not the sh and gmake shipped with CCS for this purpose.  In many cases, this is OK (and may even be preferred), but sometimes it fails.  

    The solution is to change the system path that is seen by CCS, without changing it for anything else.  Do that by modifying how CCS is started.

    This solution is specific to Windows systems.  If you use CCS on Linux, this does not apply to you.

    I presume you have a CCS icon on your desktop.  Right-click on it and choose Properties.  Select the Shortcut tab.  Modify the Target text box to something similar to this ...

    %comspec% /c path=C:\ti\ccsv6\utils\bin;C:\ti\ccsv6\utils\cygwin;%path% & C:\ti\ccsv6\eclipse\ccstudio.exe

    Here's the breakdown on that command:

    • %comspec% starts a DOS command shell.  
    • The /c option causes the shell to close when the command has completed execution
    • This is followed by two commands linked by the special character '&'
    • The first command modifies the path to prepend two directories to it.  These directories contain the preferred version of gmake and sh.  What is shown presumes your CCS installation is rooted at C:\ti (the default).  Modify that if needed.
    • The second command is the invocation of CCS itself.  This was present in the text box before any changes.

    Change Run from Normal Window to Minimized.  Click OK.

    That's all the changes!

    One disadvantage to this approach ... When you run CCS now, you see two CCS icons in the taskbar along the bottom of your screen.  The first one is a DOS command shell you cannot interact with.  The other is CCS.  Ignore the DOS command shell.  It terminates normally when you exit CCS.  

    If you try this solution, please reply to this thread to let us know about your experience.  If it works well for most users, then I will write this up in a wiki article.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 80 points
    I have been struggling with the same issue for days (actually, sometimes this error manifests as a seg fault, usually when I'm running it from mklib at the command line, but sometimes it shows as just a "library not found" type of error).

    Anyway, I figured out what the issue was for me and thought I'd share it to save others the frustration.

    I had seen lots of solutions out there about separate Cygwin installations causing a problem in your PATH. What actually happened for me is that I needed to (in addition to making sure C:\ti\ccsv5\tools\compiler\arm_5.1.1\bin;C:\ti\xdctools_3_25_06_96\bin are both in the Windows PATH), but I needed to remove the path for WinAVR_2010/bin from my path (or other similar years of WinAVR). Turns out it uses similar utilities that will mess up your build.
  • 0 in reply to George Mock
    Prodigy 10 points

    Hi George,

    Thanks for this post. I had the same fault with a new project based on default HALcoGen output.

    I followed the instructions above and it worked perfectly.

    I can reproduce the fault if I use an unmodified shortcut. 

    Thanks for this post.

    Geoff