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.

evm6437 demo program lib error

Other Parts Discussed in Thread: CCSTUDIO

<Linking>
>> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\004163, line 66:   error:
               can't find input file '/lib/evmdm6437bsl.lib'

>> Compilation failure

Build Complete,
  2 Errors, 0 Warnings, 0 Remarks.

  • The linker can't find the library.  You will need to adjust your linker search paths in the project options.  In this case since it looks like library is being included with /lib in front of it you will want add the path up until that point.

     

    For example if the library were in the following folder on my PC: C:\libraries\DM6437\lib\evmdm6437.lib

    I would need to add the following to my search path "C:\libraries\DM6437".  To be safe I would also add "C:\libraries\DM6437\lib"

    Note that this is just an example you will have to use the paths that match where the library is located on your computer.

  • Yes, but the library doesn't seem to have been distributed with either dvsdk_1_01_00_15 or dvsdk_1_11_00_00_DM648 or ccs (v3.3). I've installed lots of TI's .zips as well (e.g. FFT) and its not in there either.
  • i.e. the .pjt contains absolute references to a directory that isn't created when the tools are installed into the default places. TI must be pushing the software infrastructure out without testing it on a clean PC.
  • It has been a long time since I used that EVM but I believe it came with a CD that contained software including the board support library. That library would have been part of that software.

    If I go to the board vendors support page:
    c6000.spectrumdigital.com/.../

    I see a package called DM6437 EVM Target Content. When I download that zip I see the evmdm6437bsl.lib inside the /lib folder.

    Regards,
    John
  • Thanks, John, that worked. I have one more group of problems - perhaps you'll recognise the problem:
    >> C:\Users\KEN~1.MAC\AppData\Local\Temp\070363, line 24: error:
    can't find input file
    'C:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/palos_bios.lib'

    There's a space in KEN~1.MAC - perhaps that causing this. How can I stop the linker from looking in a path that has a space in it? I tried pointing the TEMP & TMP env. vars to C:\Temp, but that just caused worse problems!

    (I do have this library).

    p.s. every time that I enter the project, I have to repoint to the evb6437bsl.lib, yet I can edit the -i paths in it, so the .pjt isn't read only. I don't understand that!
  • I don't think the space in Ken... is causing the problem here as it is outputting a specific error message.

    Is the library in this exact path?
    C:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/palos_bios.lib
    i.e. if you paste C:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/ into windows explorer is the library there?
  • No - that was the problem. The structure of the hierarchy has changed in going from one version of the DVSDK to another. I've got a question a bout fixing it via editing debug.lkf in the queue for the moderator's approval.
  • debug.lkf gets generated as part of the build flow in CCSv3.x. If you edit it will just get overwritten next build. Depending on the edit that you want to make it should be possible to figure out where that setting is getting fed into the .lkf.
  • Yes, even though debug.lkf doesn’t appear in Generated Files in .pjt, it is rewritten on a clean build.

    RE your suggestion to "figure out where that setting is getting fed into the .lkf.", editing the complete string in the build options seems very cross coupled to me!

    even though the -m looks OK in the string & the changes ought to only affect the linker, the compiler is no longer happy:

    [video_encdec.c] "C:\CCStudio_v3.3\C6000\cgtools\bin\cl6x" -o2 -i"C:/CCStudio_v3.3/bios_5_31_08/packages/ti/rtdx/lib/c6000" -i"C:/dvsdk_1_11_00_00_DM648/pspdrivers_1_10_00/packages/ti/sdo/pspdrivers/pal_os/bios/lib/dm6437/Release" -c -m"./Debug/video_encdec.map" -"./Debug/video_encdec.out" -w -x -l"/dvsdk_1_11_00_00_DM648/pspdrivers_1_10_00/packages/ti/sdo/pspdrivers/drivers/i2c/lib/dm6437/Debug/palos_bios.lib" -l"C:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/prev_bios_drv.lib" -l"C:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/video_bios_drv.lib" -l"C:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/vpbe_bios_drv.lib" -l"C:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/vpfe_bios_drv.lib" -@"Debug.lkf" "video_encdec.c"
    >> WARNING: invalid compiler option -m./Debug/video_encdec.map (ignored)
    >> WARNING: invalid compiler option --./Debug/video_encdec.out (ignored)
    >> WARNING: invalid compiler option --w (ignored)
    >> WARNING: -x2 not supported (use -O<n> instead)
    >> WARNING: invalid compiler option --l/dvsdk_1_11_00_00_DM648/pspdrivers_1_10_00/packages/ti/sdo/pspdrivers/drivers/i2c/lib/dm6437/Debug/palos_bios.lib (ignored)
    >> WARNING: invalid compiler option --lC:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/prev_bios_drv.lib (ignored)
    >> WARNING: invalid compiler option --lC:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/video_bios_drv.lib (ignored)
    >> WARNING: invalid compiler option --lC:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/vpbe_bios_drv.lib (ignored)
    >> WARNING: invalid compiler option --lC:/dvsdk_1_11_00_00_DM648/psp_1_00_02_00/pspdrivers/lib/DM6437/Debug/vpfe_bios_drv.lib (ignored)
    "video_encdec.c", line 7: fatal error: could not open source file "xdc/std.h"
    1 fatal error detected in the compilation of "video_encdec.c".
  • Editing the string itself will be error prone. It is best to use the fields in the build options dialog to specify the options. This is a bit clunky in CCSv3.x (things have improved in the years since it was released).

    The debug.lkf file is just an options file. Basically if the length of the options string is longer than what is allowed back in Win95 days it will put some of the options into the .lkf file. Thus you can see it getting passed to both the compiler and the linker.
  • I tried to use the fields in the build options dialog to specify the options, but the /'s seem to be translated into \'s regardless of what I put into the fields. Worse still, tampering with the string seems to be a one way operation from which the .pjt file doesn't recover. Its as if the string edits are stored in another file, but despite throwing the whole directory at BeyondCompare, I can't find it, unless, of course, the file is in c:\CCS_studiov3.3 ???
  • Ken,

    In CCSv3.x the settings are stored in the .pjt file. It does not write the file though until you save the project. Until that time the representation of the project is stored in memory.

    As far as / \ this old version of CCS is windows only. That said I put paths with / in my include directories and they were written to the .pjt file and passed to the compiler on build. I would stick with windows style paths though for 3.x. Newer versions are cross platform.

    For the error you are seeing I am guessing that you have /lib/evmdm6437bsl.lib specified in the libraries box in the options. Try putting just the name of the library and then put the path in the box above it.

    Regards,
    John
  • I got this fixed thanks, by reverting to the original .pjt & being careful to edit the paths in the way that you suggested. However, there's clearly a bug in the IDE's dialog box handling that allow you to paste a string straight into the assembled string box at the top of each tab. Also, there are separate -i's for both the compiler & the linker. That's asking for trouble!
  • Good to hear you have it going. There have certainly been a lot of bug fixes in the years since CCSv3.3. Normally I would suggest upgrading but the software for that board was all created for CCSv3.x and it would be a big challenge to migrate everything.

    Regards,
    John
  • I've got the simpler demos (e.g. 648 preview) building thanks to a big string of dirs in the XDCPATH env var, & these run, having found the Lyrtech gel for the 648EVB (its only in CCS6!).

    I'm almost there with  the hostapp demo - I just need to resolve

    js: "C:/dvsdk_1_11_00_00_DM648/biosutils_1_00_02/packages/ti/bios/log/support/package.xs", line 25: exception from uncaught JavaScript throw: TypeError: Cannot call method "create" of undefined (C:/dvsdk_1_11_00_00_DM648/biosutils_1_00_02/packages/ti/bios/log/support/package.xs#25)

       "C:/dvsdk_1_01_00_15/xdc_2_95_02/packages/xdc/cfg/Main.xs", line 248

    The trouble is that this package is already in my path:

    ti.bios.log.support.sch is in

    C:\dvsdk_1_11_00_00_DM648\biosutils_1_00_02\packages\ti\bios\log\support\package

    & I have 

    \dvsdk_1_11_00_00_DM648\biosutils_1_00_02\packages\;

    in my XDCPATH, which in full is:

    /dvsdk_1_11_00_00_DM648/examples/common/evmDM6437/;
    /dvsdk_1_11_00_00_DM648/biosutils_1_00_02/packages/;
    /dvsdk_1_11_00_00_DM648/codec_engine_1_20_02/packages/;
    /dvsdk_1_11_00_00_DM648/edma3_lld_1_05_00/packages;
    /dvsdk_1_11_00_00_DM648/framework_components_1_20_03/;
    /dvsdk_1_11_00_00_DM648/framework_components_1_20_03/fctools/;
    /dvsdk_1_11_00_00_DM648/ndk_1_92_00_22_eval/;
    /dvsdk_1_11_00_00_DM648/pspdrivers_1_10_00/packages;
    /dvsdk_1_11_00_00_DM648/xdais_5_21/;
    /dvsdk_1_11_00_00_DM648/xdc_2_95_02/;
    /dvsdk_1_11_00_00_DM648/codecs_1_10_evmDM648/packages;
    /dvsdk_1_11_00_00_DM648/xdais_5_21/packages;
    /dvsdk_1_11_00_00_DM648/framework_components_1_20_03/packages/;
    /CCStudio_v3.3/bios_5_31_08/packages/;

    There are other packages under

    \dvsdk_1_11_00_00_DM648\biosutils_1_00_02\packages\;

    e.g. ti.bios.utils.sch

    the only thing that I can think of, is that I've tweaked the paths to the header files as I 

    assimilate the DVSDK, in order to get past all of the compiler preproc errors due to not having the include (-i) paths set up. Now that these are set, perhasp if I unpick my changes,  the problem will evaporate.