• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 158 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.

Original question:

TMS320C6657: A problem with rebuilding NDK. Error 5

TMS320C6670: Rebuilding NDK 2.22.3.20 yields "Warning: nothing to build;"

Forrest Deitz
Prodigy 95 points
Part Number: TMS320C6670
Other Parts Discussed in Thread: SYSBIOS

Hello,

I am following the instructions for rebuilding the NDK as listed in section 1.2 od SPRU523K and as listed in the TI wiki

which states the instructions apply to NDK version 2.21 (and higher) only.

I think I have followed the instructions correctly and yet the gmake returns an error that it there is nothing to build.

The exact warning message is:

Warning: nothing to build; the directories named after -P[RrD] don't contain any buildable packages
         -P
         -Pr ./packages
         -PR
         -PD

I found it necessary to us the --f option in gmake to force a specific directory even after updating my environment variables(Yes I did reboot).

So I am wondering if this looks more like a OS permissions issue rather than an actual make file issue.

Running gmake without specifying the directory on the command line fails:

C:\WINDOWS\system32>gmake -f ndk.mak clean
gmake: ndk.mak: No such file or directory
gmake: *** No rule to make target `ndk.mak'.  Stop.

I find this to be rather odd behavior.

My make file is listed below:

#
#  ======== ndk.mak ========
#

#
# Where to install/stage the packages
# Typically this would point to the devkit location
#
DESTDIR ?= <UNDEFINED>
#DESTDIR ?= C:\ti\ndk_2_22_03_20Rebuilt\dest
prefix ?= /
docdir ?= /docs/ndk
packagesdir ?= /packages

# USER STEP: user must define below path to xdc installation
# Set up dependencies
#XDC_INSTALL_DIR ?= C:\ti\xdctools_3_25_03_72
XDC_INSTALL_DIR ?= C:\ti\ccs1020\xdctools_3_62_00_08_core
SYSBIOS_INSTALL_DIR ?= C:\ti\bios_6_35_04_50

#
# Set location of various cgtools
# These variables can be set here or on the command line.  The ?= makes
# the command line to take precedence over the setting in this file.
#
# USER STEP: user must define below paths to compilers
ti.targets.C64P ?=
ti.targets.C64P_big_endian ?=
ti.targets.C674 ?=

ti.targets.elf.C66 ?=C:\ti\ccs1020\ccs\tools\compiler\ti-cgt-c6000_8.3.8
ti.targets.elf.C66_big_endian ?=
ti.targets.elf.C674 ?=

ti.targets.arm.elf.Arm9 ?=
ti.targets.arm.elf.A8F ?=
ti.targets.arm.elf.A8Fnv ?=
ti.targets.arm.elf.M3 ?=
ti.targets.arm.elf.M4 ?=
ti.targets.arm.elf.M4F ?=

gnu.targets.arm.M3 ?=
gnu.targets.arm.A15F ?=

#
# Set XDCARGS to some of the variables above.  XDCARGS are passed
# to the XDC build engine... which will load ndk.bld... which will
# extract these variables and use them to determine what to build and which
# toolchains to use.
#
# Note that not all of these variables need to be set to something valid.
# Unfortunately, since these vars are unconditionally assigned, your build line
# will be longer and more noisy than necessary (e.g., it will include CC_V5T
# assignment even if you're just building for C64P).
#
# Some background is here:
#     rtsc.eclipse.org/.../Command_-_xdc
#
XDCARGS= \
    ti.targets.C64P=\"$(ti.targets.C64P)\" \
    ti.targets.C64P_big_endian=\"$(ti.targets.C64P_big_endian)\" \
    ti.targets.C674=\"$(ti.targets.C674)\" \
    ti.targets.arm.elf.Arm9=\"$(ti.targets.arm.elf.Arm9)\" \
    ti.targets.arm.elf.A8F=\"$(ti.targets.arm.elf.A8Fnv)\" \
    ti.targets.arm.elf.A8Fnv=\"$(ti.targets.arm.elf.A8Fnv)\" \
    ti.targets.arm.elf.M3=\"$(ti.targets.arm.elf.M3)\" \
    ti.targets.arm.elf.M4=\"$(ti.targets.arm.elf.M4)\" \
    ti.targets.arm.elf.M4F=\"$(ti.targets.arm.elf.M4F)\" \
    ti.targets.elf.C66=\"$(ti.targets.elf.C66)\" \
    ti.targets.elf.C66_big_endian=\"$(ti.targets.elf.C66_big_endian)\" \
    ti.targets.elf.C674=\"$(ti.targets.elf.C674)\" \
    gnu.targets.arm.M3=\"$(gnu.targets.arm.M3)\" \
    gnu.targets.arm.A15F=\"$(gnu.targets.arm.A15F)\"

#
# Set XDCPATH to contain necessary repositories.
#
XDCPATH = $(SYSBIOS_INSTALL_DIR)/packages
export XDCPATH

#
# Set XDCOPTIONS.  Use -v for a verbose build.
#
#XDCOPTIONS=v
export XDCOPTIONS

#
# Set XDC executable command
# Note that XDCBUILDCFG points to the ndk.bld file which uses
# the arguments specified by XDCARGS
#
XDC = $(XDC_INSTALL_DIR)/xdc XDCARGS="$(XDCARGS)" XDCBUILDCFG=./ndk.bld

######################################################
## Shouldnt have to modify anything below this line ##
######################################################

all:
    @ echo building ndk packages ...
    @ $(XDC) -Pr ./packages

clean:
    @ echo cleaning ndk packages ...
    @ $(XDC) clean -Pr ./packages

install-packages:
    @ echo installing ndk packages to $(DESTDIR) ...
    @ mkdir -p $(DESTDIR)/$(prefix)/$(docdir)
    @ cp -rf $(wildcard ndk_*_ReleaseNotes.html) docs/* $(DESTDIR)/$(prefix)/$(docdir)
    @ mkdir -p $(DESTDIR)/$(prefix)/$(packagesdir)
    @ cp -rf packages/* $(DESTDIR)/$(prefix)/$(packagesdir)

Please Advise.

Thank You,

Forrest

  • 0
    TI__Guru**** 158605 points

    Hi,

     I'm not familiar with rebuilding NDK library. Not sure why you need to rebuild the library. I have done some searches. Per this post https://e2e.ti.com/support/processors/f/processors-forum/947275/faq-how-do-you-rebuild-the-ndk, the first link in the post has documentation on how to rebuild the NDK library for 2.21 and higher. 

     With the above said, I'm sorry that there is no longer direct support for this device on the e2e forum. Support for this device is via third party as listed below if you need further assistance. 

  • 0
    Prodigy 95 points

    Hello Charles,

    Thank you for the response.

     I do not think the issue is device related. I am working remotely and have had nothing but trouble getting permissions on the machine I am remoting in on and on the machine that is the development machine sitting on a lab bench hundreds of miles away from me.

    I am familiar with the guidance given for rebuilding the ndk.

    My question is more of a "sanity check" than anything else.

    After updating my windows 10 path variables to include the directory in which the ndk.mak file exists

    gmake claims there is no such mak file.

    I have not worked while and I am asking if I have missed something fundamental here.

    I included the contents of my ndk.mak file and I have included the gmake errors.

    Unless there is something funny about working with the ndk.mak file then I suspect something is wrong with the development machine

    user permissions or some other settings.

    Do you have any thoughts on this?

    Thank You,

    Forrest

  • 0 in reply to Forrest Deitz
    TI__Guru**** 158605 points

    HI,

       I wonder if it is XDCtools version dependent wrt to the NDK version you are trying to rebuild. 

      I don't have NDK 2.22.3.20. I have NDK 2_25.00.09. When I try to rebuild it using the below three versions, I will get different kind of errors. 

    However, if I use xdctools_3_25_00_48 then it builds properly. I will suggest you try the xdctools_3_25_00_48 for old NDK versions like yours. My NDK version is even newer than yours and it won't build with the newer versions of the XDCtools. The  xdctools_3_62_00_08_core version may be too new to work with NDK 2_25.00.09.

    You can download different xdctools versions from http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/.

  • 0 in reply to Charles Tsai
    Prodigy 95 points

    Hello Charles,

    That is interesting information about the compatibility between different versions of the NDK and XDC tools.

    I was not aware there was a newer version of the NDK. My initial test has been to rebuild the NDK to see if a rebuild fixes bugs we currently have. I was asked to do this by another engineer who thought it might use newer library sources and resolve an issue we have with losing connectivity/settings when changing settings.

    I was able to get past the build failure by changing directories to the directory of the make file itself and running gmake from there.

    It is still a mystery as to why the environment variable works for the gmake utility and not for the makefile location, however I can get the work done now and I am moving on.

    I will look at the newer libraries for the NDK and XDC tools.

    Thank You,

    Forrest