Menu

#1344 CodeCompletion plugin path setting when executing compiler is incomplete

Undefined
open
ollydbg
Bug_Report
2022-12-15
2022-12-09
zetab007
No

The original issue I encountered:
https://forums.codeblocks.org/index.php/topic,24967.0.html

I found that the CodeCompletion plugin cause this issue, if I disable the plugin, there's no missing cygwin dll error anymore.
Looking into the source, the plugin only brings in the master path of the compiler, but not the extra path.
In NativeParser::AddCompilerIncludeDirsToParser:

        // find out which compiler, if gnu, do the special trick
        // to find it's internal include paths
        // but do only once per C::B session, thus cache for later calls
        if (compiler->GetID().Contains(_T("gcc")))
            AddGCCCompilerDirs(compiler->GetMasterPath(), compiler->GetPrograms().CPP, parser);

So when I set the Cygwin dll path to the "Additional Paths" in Global Compiler Setting UI, the plugin will not use it.
Maybe it should handle the path setting like the Compiler plugin?
In CompilerGCC::SetupEnvironment, it brings in both master & extra path when setting PATH environment variable.

Discussion

  • ollydbg

    ollydbg - 2022-12-09

    So, you mean the fix could be just adding the extra path of the compiler plugin?

     
  • zetab007

    zetab007 - 2022-12-10

    Yes, I think that should fix the issue.
    Also note that there might be multiple places to add the extra path, since I got the missing dll error message at least 4 times when I load first project after launching codeblocks.

     
  • ollydbg

    ollydbg - 2022-12-13

    Hi, I looked at this issue today. The actual command to run the gcc is in this function:

    // These dirs are the built-in search dirs of the compiler itself (GCC).
    // Such as when you install your MinGW GCC in E:/code/MinGW/bin
    // The built-in search dir may contain: E:/code/MinGW/include
    const wxArrayString& NativeParser::GetGCCCompilerDirs(const wxString& cpp_path, const wxString& cpp_executable)
    {
        wxString sep = (platform::windows ? _T("\\") : _T("/"));
        wxString cpp_compiler = cpp_path + sep + _T("bin") + sep + cpp_executable;
        Manager::Get()->GetMacrosManager()->ReplaceMacros(cpp_compiler);
    
        // keep the gcc compiler path's once if found across C::B session
        // makes opening workspaces a *lot* faster by avoiding endless calls to the compiler
        static std::map<wxString, wxArrayString> dirs;
        static wxArrayString cached_result; // avoid accessing "dirs" too often (re-entry)
        cached_result = dirs[cpp_compiler];
        if ( !cached_result.IsEmpty() )
            return cached_result;
    
        TRACE(_T("NativeParser::GetGCCCompilerDirs: Enter"));
    
        // for starters, only do this for gnu compiler
        //CCLogger::Get()->DebugLog(_T("CompilerID ") + CompilerID);
        //
        //   Windows: mingw32-g++ -v -E -x c++ nul
        //   Linux  : g++ -v -E -x c++ /dev/null
        // do the trick only for c++, not needed then for C (since this is a subset of C++)
    
        // Different command on Windows and other OSes
    #ifdef __WXMSW__
        const wxString args(_T(" -v -E -x c++ nul"));
    #else
        const wxString args(_T(" -v -E -x c++ /dev/null"));
    #endif
    
        wxArrayString output, error;
        if ( !SafeExecute(cpp_path, cpp_executable, args, output, error) )
            return cached_result;
    
        // wxExecute can be a long action and C::B might have been shutdown in the meantime...
        if ( Manager::IsAppShuttingDown() )
            return cached_result;
    
        // start from "#include <...>", and the path followed
        // let's hope this does not change too quickly, otherwise we need
        // to adjust our search code (for several versions ...)
        bool start = false;
        for (size_t idxCount = 0; idxCount < error.GetCount(); ++idxCount)
        {
            wxString path = error[idxCount].Trim(true).Trim(false);
            if (!start)
            {
                if (!path.StartsWith(_T("#include <...>")))
                    continue; // Next for-loop
                path = error[++idxCount].Trim(true).Trim(false);
                start = true;
            }
    
            wxFileName fname(path, wxEmptyString);
            fname.Normalize(wxPATH_NORM_DOTS | wxPATH_NORM_TILDE | wxPATH_NORM_ABSOLUTE | wxPATH_NORM_LONG | wxPATH_NORM_SHORTCUT);
            fname.SetVolume(fname.GetVolume().MakeUpper());
            if (!fname.DirExists())
                break;
    
            dirs[cpp_compiler].Add(fname.GetPath());
    
            CCLogger::Get()->DebugLog(_T("NativeParser::GetGCCCompilerDirs: Caching GCC default include dir: ") + fname.GetPath());
        }
    
        TRACE(_T("NativeParser::GetGCCCompilerDirs: Leave"));
        return dirs[cpp_compiler];
    }
    

    Here, I don't see the CodeCompletion plugin has to tweak the PATH environment variable. It just call the command.

    Now, to handle this issue, I have two solutions, but both of those two solutions are not related to CodeCompletion plugin.

    1, you can use the Environment variable plugin to add the extra path of your GCC path to the PATH.

    2, you can tweak some compiler plugin source code to add the extra path to your PATH.

    For me, I think the first solution is simple.

     

    Last edit: ollydbg 2022-12-13
  • zetab007

    zetab007 - 2022-12-13

    Here, I don't see the CodeCompletion plugin has to tweak the PATH environment variable. It just call the command.

    So the extra path was not designed to be applied when executing compiler executable?

     
  • zetab007

    zetab007 - 2022-12-14

    I made a patch to CoceCompletion plugin for this issue. I have test it on my project, no missing dll error appeared.

     
  • ollydbg

    ollydbg - 2022-12-14

    Hi, @zetab007, thanks for the patch.

    I just looked at the patch, and I see that you have add the extra path when running the command, so you are correct. I was wrong that I said CodeCompletion plugin did not tweak the PATH variable.

    In-fact, it adds the master path temperately, and later reset the PATH.

    You patch just adding extra path to the PATH variable.

     
  • zetab007

    zetab007 - 2022-12-14

    Hi @ollydbg,
    I'm not very familiar with CodeCompletion plugin, just made a quick modification to fix the issue. So if you find any inappropriate change, you could correct it.

    Another thing, I also found some very similar functions in clangd_client plugin when I was searching in the source tree, but I didn't touch them. Maybe that plugin will have similar issue.

     
  • ollydbg

    ollydbg - 2022-12-15
    • labels: --> CodeCompletion
    • assigned_to: ollydbg
     
  • ollydbg

    ollydbg - 2022-12-15

    I think I will commit your patch to the SVN.

    I don't have cygwin, but I see the patch is correct.

    I fix a build error compiler->GetExtraPaths should be compiler->GetExtraPaths(), and add a doxygen document about SafeExecute function.

     
  • ollydbg

    ollydbg - 2022-12-15

    It is fixed in r13117 now.

    Now, I guess the clangd_client plugin also need such fix.

    Let's ask @pecan, what's your opinion?

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.