• Locked Locked
  • Replies 9 replies
  • Subscribers 53 subscribers
  • Views 1214 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.

CCS 4.2 compile error: "longer than _MAX_PATH"

ReinierC
Expert 2425 points


Hi,

I'm currently busy porting a massive project of ours from CCS 3.3 to CCS 4.2.

I'm porting the project module for module, and for the current module I get the

following compiler error:

"D:\Rapid_Mobile\projects\client-rapidm\product-wp_tc4_reference_system\make\tc4_rev06\module-hfh_interface_lib\..\..\..\source\dependencies\module-rm_s4538_arcs\s4538-protocol\s4538_node\include\..\..\interfaces\include\../../flsu_ftm/include/flsu_lsu.h", line 21: fatal error: "D:\Rapid_Mobile\projects\client-rapidm\product-wp_tc4_reference_system\make\tc4_rev06\module-hfh_interface_lib\..\..\..\source\dependencies\module-rm_s4538_arcs\s4538-protocol\s4538_node\include\..\..\interfaces\include\..\..\flsu_ftm\include\../../interfaces/include/s4538_wave_if.h" is illegal as it is longer than _MAX_PATH
1 fatal error detected in the compilation of "D:/Rapid_Mobile/projects/client-rapidm/product-wp_tc4_reference_system/source/module-wp_radio_control_manager/hfh_conn_process_radio_control_manager.cpp".
Compilation terminated.

From similar problem I found that the reason for this is because the Windows XP API

limits the path length to 260 characters, so this is partly an OS problem. However, I

cannot understand how the compiler searches for header files. I'm currently only compiling

a single source file, but because of the complexity of the project there are multiple

layers of includes, for this case it happens as follows:

I'm trying to compile "hfh_conn_process_radio_control_manager.cpp",

(the contents are not important) which includes: hfh_conn_process_s4538_arcs.h,

which in turn includes: s4538_node.h,

which in turn includes: s4538_dte_if.h,

which in turn includes: flsu_lsu.h,

which in turn includes: s4538_wave_if.h

At this point the _MAX_PATH length is reached and the compiler gives up.

What I have noticed is that the compiler appends the next header path (which

is specified in some cases in the header file, relative to its location) to the

current search path. Consequently the search path becomes longer and

longer with each nested include until it crashes. Due a few previous design

decisions/constraints I inherited , I can't simply remove the relative paths in

the header files and only specify it as an include path in the build options.

Is this behavior expected or am I doing something seriously wrong?

Does anyone perhaps have a suggestion?

Please provide as many suggestions as possible.

Thanks in advance!

Reinier

  • TI__Guru**** 173310 points

    Reinier,

    The message you are seeing is expected behavior for current versions of the compiler. The parser uses fopen to check if an include file exists on a given path, and on Windows, the path passed to fopen can contain a maximum of 260 characters (This is a Windows specific limit defined in _MAX_PATH).

    In older versions of the codegen tools we were not doing a check to see if the path was within 260 characters, so in some cases the fopen would fail silently or pick up an include file from a different path (if a file of the same name also existed in a different include path). As a result, we added a check to check for path length and if it exceeded MAX_PATH then we generated an error, so the user is informed about what is happening rather than silently producing unexpected behavior.

    The tracking # we had used for this issue was SDSCM00008189 and you can look up some details on it using the SDOWP link in my signature below.

    Based on the information, it seems like you would need to modify your header file inclusions or include paths to work around this.
    I'll also move this thread to the compiler forum in case the experts there have further suggestions or comments.

  • in reply to AartiG
    Expert 2425 points

    Hi AartiG,

    Thank you for your response.

    I have tried to use "\\?\" before my include path, but the parser automatically

    changes the backslashes to forward slashes, so that did not make a difference.

    The way the previous codegen tools worked would actually be better for this

    particular case, since I already have the correct include path configured in my

    build settings. But now because an error is generated it never gets a chance

    to search the correct include paths as configured in the build settings.

    As I mentioned before, editing the include paths in the header files should

    be a last resort, since it will result in multiple dependency issues in our project.

    Do you (or anyone else) have any other concrete workarounds?

    Regards

      Reinier

  • in reply to ReinierC
    TI__Guru* 84285 points

    "\\?\" is the prefix for "long UNC" (UNC is Microsoft Windows "Univeral Naming Convention"), but I'm pretty sure the compiler doesn't support it.

  • in reply to Archaeologist
    Expert 2425 points

    Well, I've migrated the whole environment from Windows XP to Windows 7,

    which was suppose to allow a path longer than 260 characters, but alas I

    get the same compiler error!

    Our code compiles perfectly with codegen tools 5.1.3, so why is it so difficult

    to migrate to 7.0.3??

    Can someone perhaps give me a concrete approach to solve this problem?

    After hours of searching the Internet it appears that only a few people are

    actually aware of the problem, but no one really knows how to solve it.

  • in reply to ReinierC
    Expert 2425 points

    *Bump bump*... Is there anybody that knows how to solve this MAX_PATH problem??

  • in reply to ReinierC
    TI__Guru* 84285 points

    Based on what little I know of how it is handled, with the current tools, you will probably have to change the #include statements so that they don't include ".." path segments.

    If there is other advice available, I don't know it.

  • in reply to Archaeologist
    TI__Guru**** 251100 points

    Purely FYI, but interesting to know ... Processing to remove ".." in directory paths is more difficult than it looks.  You have to consider the effect of symbolic links.  If /links_elsewhere is symbolically linked to /real1/real2, then the path /links_elsewhere/../myheader.h corresponds to /real1/myheader.h, and not /myheader.h.  You have to expect such links and follow them.  I'm not sure, but I suspect that the only practical solution is to leave all this processing to system calls in the OS.  I don't know that a uniform set of such system calls exist across Windows and Linux.

    Thanks and regards,

    -George

  • in reply to George Mock
    Expert 2425 points

    Thank you for your replies, but I'm afraid it does not help me much.

    The problem is that project is really big and complex, so its not as

    simple to just remove the ".." directory path, as it will break all the

    other code/projects depending on it. In addition, the design I inherited

    uses ".." in the includes to specify platform independent header files

    and the includes without any ".." refers to platform specific header 

    files, in which case the path is specified in the build options.

    The problem is that the compiler immediately throws an error when

    MAX_PATH is exceeded, which is in this case not a valid path anyway.

    If it had ignored the MAX_PATH and moved on to the next search path,

    it would eventually find the correct path and compile successfully. This

    is what the previous versions of the code generation tools did and our

    code compiled successfully with it.

    Is it not possible to disable the MAX_PATH check somehow?

  • in reply to ReinierC
    TI__Guru**** 251100 points

    I'm sorry, but the only solution available at present is removing the ".." in the include statements.

    Thanks and regards,

    -George