• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 690 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler Version detection fails

Raymond Mack
Expert 1575 points

I am still rebuilding the driver library from the command line:

c:\ti\xdctools_3_30_01_25_core\gmake -d -f tirtos.mak drivers

I am rebuilding yet again because the linker now complains that my driver library was built using a different version of the compiler than being used to build my project.  The compiler version in the library is blank.

Lines 293 and 407 of ITarget.xs try to get the compiler version:

        if (xdc.exec(cmd, attrs, status) >= 0) {
However I get the following response:

ti.targets.arm.elf.M4F: warning: exec of '/ti/ccsv6/tools/compiler/arm_5.1.5/bin/armcl --compiler_revision' failed:Cannot find /ti/ccsv6/tools/compiler/arm_5.1.5/bin/armcl along the path [c:\bin, c:\WINDOWS\system32, c:\WINDOWS, c:\WINDOWS\System32\Wbem, c:\WINDOWS\System32\WindowsPowerShell\v1.0, c:\Program Files\Adobe\Adobe PDF iFilter 11 for 64-bit platforms\bin, c:\Program Files (x86)\WinMerge, c:\Program Files\TortoiseSVN\bin, c:\QNX650\host\win32\x86\usr\bin, c:\Program Files (x86)\QNX Software Systems\bin, c:\ti\xdctools_3_30_0
1_25_core\bin]; check tools installation

Based on what I see, the xdc.exec function is trying to find the compiler by searching the Windows path variable. It does not find armcl because nothing in the TI install sets up the compiler path in the Windows environment.  Of course this fails.  It looks like xdc.exec is defective somehow because it should have found armcl.exe using the "cmd"  pathname. It is instructive that the error report also has the xdc tools directory in the set of paths that it searches.  I am going to guess that this is an artifact of removing the drive letter from the install directory at line 10 of tirtos.mak as a workaround for yet another bug.

Adding this line above line 407 seems to solve the problem:

cmd = "c:" + cmd;

Makes me wonder how many more of these small things that *ought* to work but do not that I will find.

  • 0
    TI__Mastermind 37985 points

    Raymond,
    the compiler path is set in tirtos.mak using DEFAULT_INSTALLATION_DIR, and that's an absolute path. If that variable is changed in such a way that the remaining relative path cannot be found from PATH, there is no really a way for XDCtools to find the compiler. Your workaround will work for this particular case, but if you end up invoking getVersion() for a different build, you could have a different error with the path that starts with "c:c:".
    I am not sure why should xdc.exec find armcl in the set of paths. There is no component in that set of paths that could be a valid prefix to the compiler path.

    I don't know which bug requires removing the drive letter from tirtos.mak, but there could be a different workaround for it, which wouldn't break other components.

  • 0 in reply to Sasha Slijepcevic
    Expert 1575 points

    I had a note on Tuesday in the Code Composer forum that the Unix to DOS "path mangler tool" was converting "C:/" into "C;C:\" instead of converting it to "C:\"  I suspect it has something to do with building the driver library from the DOS command line rather than through the Eclipse IDE.

    I am also not sure why this got moved to the RTOS forum when this is clearly a problem with generic Code Composer rather than specific to RTOS.

    Ray

  • 0 in reply to Raymond Mack
    Expert 1575 points

    Sent the last message too soon...

    The work around I mentioned for getting the compiler version operation to work was necessary because of the path mangler bug I mentioned.  I did a lot of investigation going through the various steps performed by the xdc system and narrowed it down to a problem with the unix2dos (not sure of exact name) tool used to convert the path.  I am not sure why you are changing the path because DOS will handle Unix style paths.  Try typing at the command prompt:

    c:/ti/xdctools_3_30_01_25_core/gmake

    you will see that it works quite nicely on Windows 7 and Windows 8.  Not sure about XP, but you should probably drop support for XP anyway.

    Now that I think of it, I will try commenting out the path mangler command and see if it starts working again. News when I get to work.


    Ray

  • 0 in reply to Raymond Mack
    Expert 1575 points

    Sasha:

    I see your name on some of the build component scripts.  It is good to talk directly to the one who did the work!

    I am pretty sure I found the source of the problem.  "sh.exe" is executed from the machine's path in the environment rather than using the "sh.exe" containd in "xdctools_3_30_01_25_core/bin".

    In my case I had a version of bash from mingw that was set up as sh.exe and would execute from my path environemnt. For some reason, this version gives different results from using the cygwin version of "sh.exe" that y'all include.


    It seems probable that I have at least 3 different versions of sh.exe in the path on my machine: One from QNX, one from mingw, and one from CCSv6.  I doubt my situation is unique.

    Is there a way to force sh.exe to be run from xdctools_3_30_01_25_core/bin so this is prevented?  I know that this kind of configuration issue is a real problem for you for implementing and testing.  Being able to force all tool use to be from what you ship is definitely a  good way to ensure that local machine issues don't pollute your products.

    I just did a rebuild of the driver library after copying the cygwin shell into my mingw directory (getting rid of the old BASH install) and it now builds correctly from the command line as nearly as I can tell!!

    Thanks.

    Ray

  • 0 in reply to Raymond Mack
    TI__Mastermind 37985 points

    Ray,
    I responded in your other thread: http://e2e.ti.com/support/embedded/tirtos/f/355/t/353691.aspx, and I added a link to a longer discussion about XDCtools in cygwin. In short, xdc.exe command is just a simple shell around gmake, and gmake invokes sh.exe, here are the rules how gmake does it: http://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html#Choosing-the-Shell.

    We do set SHELL to our sh.exe in xdc.mak in packages/xdc/bld, which should be enough based on gmake docs, but it's not working. So, in your case it's best to remove any other sh.exe from the path when using XDCtools and it seems to be working.