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

random error #10008-D: cannot find file "-lG:\starcd\gtest\Debug\gtest.lib"

Emmanuel Auclair
Prodigy 140 points


Hi,

sometimes, my CCS decides that it can't find a library file when linking.

- the path to the library is correctly set in the file search options of the linker.

- the file DOES exist on the disk, in the correct directory (in fact other projects can link with it without problem).

the problem appears/disappears randomly for me an a co-worker. only solution found up to now is to delete the project and re-create it, which is NOT user-friendly.

I'm using CCS v5.4.0.00091 (see config file)8484.config.txt

  • 0
    Guru 192875 points

    Hi,

    You're experiencing some kind of instability with the compiler. Here are few things you can try out:

    1. Complete un-installation and fresh installation  OR

    2. Create a new workspace -> create a new project -> Copy your code 

    Let me know if any of these work.

    Regards,

    Gautam

     

  • 0 in reply to Gautam Iyer
    Prodigy 140 points

    Hi,

    1. funnily enough, I just did that yesterday and the problem is unfortunately still there.

    2. In fact I'm in the process of recreating my workspace and recompiling all my projects :)

    This problem was already present (and visibly random) in my previous installation/workspace and on the computer of my coworker :(

  • 0 in reply to Emmanuel Auclair
    Guru 192875 points

    Ohhh...So sorry! That sounds very tiresome. I know, dealing with such kind of instability tests your patience. I hope a TI employee rescues you soon. Maybe you'll have to wait for another 3-4hrs for their reply. Good luck!

    Regards,

    Gautam

  • 0 in reply to Gautam Iyer
    Prodigy 140 points

    thx for the prompt suggestions anyway ;)

  • 0 in reply to Emmanuel Auclair
    Prodigy 140 points

    ok, think I've found the problem : in fact the path of ANOTHER library is wrong and the generated flag result in -l"", which probably breaks the parsing of flags, and the linker systematically report the last library flag of the command line to be missing, instead of correctly reporting the -l"" (include flags work correctly and reports the missing dir in -I"").

    would be great to correct the error msg, in case anybody(else) spends more time on this...

  • 0 in reply to Emmanuel Auclair
    TI__Guru**** 173310 points

    Emmanuel Auclair said:
    would be great to correct the error msg, in case anybody(else) spends more time on this.

    To determine if this is a bug and fix the error message we would first need to reproduce the behavior. Would you be able to share your project or a cutdown test case that we can use to reproduce this?

  • 0 in reply to Emmanuel Auclair
    Guru 192875 points

    Great, Congrats.

    Cheers,

    Gautam

  • 0 in reply to AartiG
    Prodigy 140 points

    hi,

    sorry for the late answer but we are in kind of a rush here and I've not been able to repeatedly reproduce this behaviour. If I insert volontarily a wrong path in the linked libraries files, the linker correctly reports the wrong path.

    The problem seem to appears when the path is technically correct according to the css workspace but the lib file itself is absent, or the path changed in the library project we depend upon for linking (no better explanation a the time).

    The best I can do for you is attach the log file of a compilation with the buggy behaviour that happened to my coworker this morning. As you can see the linker complains it doesn't find the "gtest.lib" (which in fact exists at the given path) but the true error is that the previous library flag on the command line is missing (-l"").

    this library flag should be defined with the path to another of our libraries, but the name of the project for this library changed in the workspace and the config file used by the linker as been updated with the new path, but we forgot to build the library before.

    All this happens a lot when we rename projects and a cowoker pulls the modifications from version manager.

    regards,

    Emmanuel

  • 0 in reply to Emmanuel Auclair
    TI__Guru**** 173310 points

    Emmanuel Auclair said:

    The best I can do for you is attach the log file of a compilation with the buggy behaviour that happened to my coworker this morning. As you can see the linker complains it doesn't find the "gtest.lib" (which in fact exists at the given path) but the true error is that the previous library flag on the command line is missing (-l"").

    this library flag should be defined with the path to another of our libraries, but the name of the project for this library changed in the workspace and the config file used by the linker as been updated with the new path, but we forgot to build the library before.

    I was able to construct a similar error by specifying a parameter to --library option that is a build variable which is not defined.

    I think the error is misleading in saying that it cannot find the library file that appears next on the command line, when in fact, it should actually be reporting on the empty parameter to the previous -l option.

    I have submitted bug # SDSCM00048257 which you should be able to track using the SDOWP link in my signature.