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.

Unix to DOS java code is broken



I am building the EMAC code to fix the broken EMAC on Tiva 129.  Here is my command line:

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

Here is the tail of the build process:

Building 'ti.targets.arm.elf.M4F' using 'c;c:\ti\ccsv6\tools\compiler\arm_5.1.5' ...
ccOpts.suffix =  -ms -g --gcc --define=ccs
js: "C:/ti/tirtos_tivac_2_00_01_23/products/bios_6_40_01_15/packages/ti/targets/ITarget.xs", line 268: Error: c;c:\ti\ccsv6\tools\compiler\arm_5.1.5 cannot be found. Ensure that r
otDir for the M4F target is set correctly in c:/ti/tirtos_tivac_2_00_01_23/tirtos.bld
    "C:/ti/tirtos_tivac_2_00_01_23/products/bios_6_40_01_15/packages/ti/targets/arm/elf/IArm.xs", line 150
gmake[1]: *** Deleting file `package.mak'
gmake[1]: *** No rule to make target `package.mak', needed by `.interfaces'.  Stop.
xdctools_3_30_01_25_core\gmake.exe: *** [packages/ti/drivers,.interfaces] Error 2
gmake: *** [drivers] Error 2

You will notice that the path names begin with "c;c:\ti".  This is the error.  For some reason, the conversion from DEFAULT_INSTALLATION_DIR ?= c:/ti to "c:\ti" gets mangled inside the xdc process.  Here is the middle part where the xdc tool gets called (with -d flag on make):

building tirtos packages ...
Reaping winning child 0x02bafcf8 PID 45815456
Cleaning up temp batch file c:/temp/make6136-1.sh
Creating temporary batch file c:/temp/make6136-1.sh
Batch file contents:
        c:/ti/xdctools_3_30_01_25_core/xdc XDCARGS="TivaWareDir='c:/ti/tirtos_tivac_2_00_01_23/products/TivaWare_C_Series-2.1.0.12573c' ti.targets.arm.elf.M4F='c:/ti/ccsv6/tools/c
mpiler/arm_5.1.5'" XDCBUILDCFG=./tirtos.bld -Pr ./packages
CreateProcess(c:\bin\sh.exe,c:/bin/sh.exe c:/temp/make6136-1.sh,...)
Live child 0x02bafcf8 (drivers) PID 45815456
making all: Tue Jul 8 13:16:59 CDT 2014 ...
======== .interfaces [./packages/examples] ========
======== .interfaces [./packages/examples/DK_TM4C123G] ========
======== .interfaces [./packages/examples/DK_TM4C129X] ========
======== .interfaces [./packages/examples/EK_LM4F120XL] ========
======== .interfaces [./packages/examples/EK_TM4C123GXL] ========
======== .interfaces [./packages/examples/EK_TM4C1294XL] ========
======== .interfaces [./packages/examples/examplesgen] ========
======== .interfaces [./packages/ti/drivers] ========
making package.mak (because of package.bld) ...
Argument 'c:/ti/tirtos_tivac_2_00_01_23/tirtos.bld
targetName c:/ti/tirtos_tivac_2_00_01_23/tirtos.bld
rootDir undefined
Argument 'TivaWareDir=c;c:\ti\tirtos_tivac_2_00_01_23\products\TivaWare_C_Series-2.1.0.12573c
targetName TivaWareDir
rootDir c;c:\ti\tirtos_tivac_2_00_01_23\products\TivaWare_C_Series-2.1.0.12573c
Argument 'ti.targets.arm.elf.M4F=c;c:\ti\ccsv6\tools\compiler\arm_5.1.5
targetName ti.targets.arm.elf.M4F
rootDir c;c:\ti\ccsv6\tools\compiler\arm_5.1.5

You can see that the path is correct as it is passed in to xdc.exe, but it dies during the process of changing from Unix style path to DOS style path.

Changing line 10 of tirtos.mak from:

DEFAULT_INSTALLATION_DIR ?= c:/ti

to:

DEFAULT_INSTALLATION_DIR ?= /ti

is a workaround for the problem.  Seems very unlikely that you would build on a drive different from where the tools are installed, but that is a danger of this workaround.

 

Ray

PS: It is *NOT* necessary to convert from Unix to DOS if you use regular fopen() calls and probably system() calls.  Windoze uses Unix style internally (from its legacy from SCO Unix and Windows NT).  It is just CMD.EXE that is screwed up and requires the wrong slashes.

  • After a lot of digging, I discovered that this is an artifact of a mingw version of sh.exe being in my default path.  Instead of using the cygwin version in c:\ti\xdctools_3_30_01_25_core\bin, it was pulling in the mingw version which somehow handles the path conversion process differently.  Moving the cygwin version into my default path solved the issue.

    I will reiterate that the path does not need to be changed from Unix style syntax to DOS style syntax.  Microsoft finally did something reasonable and fixed Windows.  c:/ti/xdctools_3_30_01_25_core/bin/sh.exe will execute from a system() call or from a cmd.exe prompt the same as c:\ti\dctools_3_30_01_25_core\bin\sh.exe.

    It probably points to a question of why the exec function does not use the xdc install variable to point directly at the sh.exe that is shipped as part of CCSv6.

    Ray

  • Raymond,

    Yes there is no need to change the path from UNIX style slashes to Windows style. XDC expects the UNIX style paths. Glad you figured it out.

    Thanks,

    Moses

  • Raymond,
    XDCtools doesn't do conversion from Unix to DOS. Once you remove your mingw version of cygwin from your path, you can go to ti/targets/ITarget.xs, and right above the line 268 add:
    print("rootDir:" + target.rootDir);
    and you should see a Unix-style path, which is what I am seeing:
    rootDir: c:/CCS6/ccsv6/tools/compiler/arm_5.1.5
    So, it's cygwin that does that and we don't have any control over it. BTW, we had problems with cygwin versions before and here is a thread which answers in more details why we can't easily handle different cygwin versions:
    https://www.eclipse.org/forums/index.php?t=msg&th=152071&start=0&S=e354daba09d135def6f299c20307ab0f