• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 931 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.

NDK version available via preprocessor?

David Negro
Intellectual 330 points

NDK 2.24.00.11 removed the length fields from the socket address structures as documented in the Release Notes:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/2_24_00_11/exports/ndk_2_24_00_11/ndk_2_24_00_11_release_notes.html#Upgrade_Info

I have several products I need to simultaneously support with our code base some of which still need to use older versions of the NDK.  Do any of the NDK header files define a preprocessor macro which describes the version that I could then use to conditionally compile our code?  For example I want to set the sa_len field of sockaddr for older NDK versions but obviously that field is absent in the new NDK.  I could define my own preprocessor macro for each NDK version used, but I would prefer not to put that burden on our build system if possible.

Any tips for supporting multiple NDK versions is much appreciated.

Thanks,

-DaveN

  • 0
    TI__Mastermind 45025 points

    Hi DaveN,

    Thinking about some ways to help you solve this.  How many different versions of the NDK are you currently supporting?

    (below edits added to original post)

    What method do you use to build your different products? (i.e. makefiles?  CCS projects? Other?)

    Steve

  • 0 in reply to Steven Connell
    Intellectual 330 points

    Steve,

    We support at least 3-4 NDK versions at a given time.  Basically a product will RTM with a particular version of NDK and we don't change it for that particular product unless there is a good need.  Our software code base will of course advance as we need to introduce new features / bug fixes etc.  New products generally need new versions of the NDK because of the added support for new processors.  All our products share the common code base.

    Thanks,

    -DaveN

  • 0 in reply to David Negro
    Intellectual 330 points

    Okay, I guess there is no compile time way to determine the NDK version.  I added our own method to our build system.  I am assuming that the directory name ends in ndk_MAJ_MIN_XX_YY and then my makefile parses out the version information from the directory name (which we pass in using the variable "TI_NDK_DIR").  For those that are interested...

    # This makefile is used to determine the version of the TI NDK in use
    # It tries to do this by parsing the directory name

    ifdef TI_NDK_DIR
    ifndef TI_NDK_MAJOR_VERSION

    _TMP := $(TI_NDK_DIR)
    # begin by breaking up the directory in each of the directory compmonents
    _TMP := $(subst /, ,$(_TMP))
    _TMP := $(subst \, ,$(_TMP))
    _TMP := $(strip $(_TMP))
    # we are interested in the lsat directory component
    _TMP := $(lastword $(_TMP))
    # we expect this to be in the form ndk_MAJ_MIN_X_Y
    _TMP := $(subst _, ,$(_TMP))

    override _TOLOWER:=$(firstword $(_TMP))
    ifneq ("$(_TOLOWER)","ndk")
    $(warning "Expecting last directory in TI_NDK_DIR to be of form ndk_MAJ_MIN_XX_YY instead TI_NDK_DIR= \"$(TI_NDK_DIR)\"")
    endif

    export TI_NDK_MAJOR_VERSION:=$(word 2,$(_TMP))
    export TI_NDK_MINOR_VERSION:=$(word 3,$(_TMP))

    override CPPFLAGS+=-DTI_NDK_MAJOR_VERSION=$(TI_NDK_MAJOR_VERSION) -DTI_NDK_MINOR_VERSION=$(TI_NDK_MINOR_VERSION)

    #$(warning TI_NDK_MAJOR_VERSION=$(TI_NDK_MAJOR_VERSION))
    #$(warning TI_NDK_MINOR_VERSION=$(TI_NDK_MINOR_VERSION))
    endif
    endif

    -DaveN

  • 0 in reply to David Negro
    TI__Mastermind 45025 points

    Hi DaveN,

    Nice clever work there!

    Researching this a bit, it seems that this is an issue with the original implementation of the NDK.  It looks like the standard way of checking for the length member being present is for a stack/OS to define constants such as SA_LEN or SIN_LEN or SIN6_LEN.  So, when developing a TCP/IP stack, if the author decides to define such length members, then these macros should be defined.

    Unfortunately the NDK (when originally implemented to have those length members) never added defines such as these, to allow a user to check for existence or not.  If it had, I think your problem would have been solved.

    When adding the BSD support layer and hence removing those length fields, I believe the proper thing to do would have been to no longer define such macros (i.e. remove them if they existed in the NDK).  Since the current NDK 2.24 doesn't have those defined, I think it's correct from this perspective (although this still doesn't help you).

    One option would be to re-release/patch all previous versions of the NDK (prior to version 2.24 which had the length members) to define those macros.  However, I'm not sure how feasible this option is, given the number of prior releases and that they will be phased out by the 2.24.x (and newer) streams.

    In any case, I've filed a bug to track this, so that if I make a patch release to NDK 2.23.x, to add such macros.

    SDOCM00113056 - legacy sockets layer should define macros for detecting presence of SIN_LEN, etc. fields (for patch release to older NDK)

    Steve