Googled it and scoured this site for a couple of days. Now I'm asking.
Why is it that when I "#include rpc.h" the compiler always throws me a "error: rpc.h: No such file or directory"?
My search directories (compiler) are:
..\..\..\usr\x86_64-w64-mingw32\sys-root\mingw\include
C:\cygwin\usr\x86_64-w64-mingw32
C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include
My BuiltIn fields are:
base: C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw
Include: C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include
My Selected compiler is Cygwin GCC
My rpc.h file is: C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\rpc.h
Did you try turning on full compiler logging and reading the build logs?
http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28errors%29#Q:_How_do_I_troubleshoot_a_compiler_problem.3F (http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28errors%29#Q:_How_do_I_troubleshoot_a_compiler_problem.3F)
Edit: You do know that you are still likely mixing Cygwin and MinGW headers and this is likely NOT to work.
Tim S.
All the Build Log shows is this:
-------------- Clean: Release in rap00 ---------------
Cleaned "rap00 - Release"
-------------- Build: Release in rap00 ---------------
Compiling: main.c
In file included from C:\cygwin\home\eb\rap00\main.c:10:
C:\cygwin\home\eb\rap00\rap.h:10:17: error: rpc.h: No such file or directory
In file included from C:\cygwin\home\eb\rap00\main.c:10:
C:\cygwin\home\eb\rap00\rap.h:310: error: expected ')' before '*' token
C:\cygwin\home\eb\rap00\main.c: In function 'rapvar_read_name_1':
C:\cygwin\home\eb\rap00\main.c:40: warning: function returns address of local variable
C:\cygwin\home\eb\rap00\main.c: In function 'main':
C:\cygwin\home\eb\rap00\main.c:47: warning: unused variable 'Pclient'
Process terminated with status 1 (0 minutes, 0 seconds)
2 errors, 2 warnings
I was under the assumption that I set something wrong and need to be pointed to the proper setting.
Also, I'm trying to use only the mingw headers/libs that came via the cygwin installer.
I'm hoping they already have a facility for this problem.
Quote from: stahta01 on January 20, 2012, 03:12:11 AM
Did you try turning on full compiler logging and reading the build logs?
http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28errors%29#Q:_How_do_I_troubleshoot_a_compiler_problem.3F (http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28errors%29#Q:_How_do_I_troubleshoot_a_compiler_problem.3F)
I suggest you also read my response in the cboard forum; which I am guessing was started by you.
http://cboard.cprogramming.com/c-programming/145288-undefined-reference-clnt_create.html (http://cboard.cprogramming.com/c-programming/145288-undefined-reference-clnt_create.html)
Feel free to keep the Code::Blocks questions in this thread; but, I think the root cause of your problem is a Compiler question that is not correct to post this forum.
Tim S.
Thanks Tim. Didn't see that last post over there until now.
And in my defense my original question over here is (basically):
What is the proper CodeBlocks setting so that when I #include <rpc.h> the compiler looks for C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\rpc.h?
A a related problem/question is:
If you look at my settings (see previos reply) why is it that #include "tirpc/rpc/clnt.h" leads me to C:\cygwin\usr\include\tirpc\rpc\clnt.h when I do not have "C:\cygwin\usr\include" entered as any of my settings. I did before but as you see I have removed them AND restarted CodeBlocks.
Again I apologize for the elementary question but the online manual has me befuddled.
"And another thing!..."
This may help someone figure out what i'm doing wrong:
If I add "C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\rpc.h" to the project, I can right click-> Open #include file: 'rpc.h' and it with open the proper file but the compiler still can't find it.
fyi - I have Compiler logging: set to Full command line.
My other 2 choices are 'Task description' and 'No logging'.
Quote from: eb on January 20, 2012, 09:37:37 PM
fyi - I have Compiler logging: set to Full command line.
My other 2 choices are 'Task description' and 'No logging'.
That can be true; but, if you do NOT post the full build log after a full rebuild; then it really does NOT help us help you.
Edit: You do realize that you are likely wasting your time. Getting MinGW64 headers to work with the Cygwin compiler is NOT easy and may be impossible!!
Tim S.
That may be so but my immediate problem is getting Code Blocks to work properly.
For instance I have just changed my Compiler logging setting from 'Full command line' to 'No logging', I executed a 'Rebuild workspace' and the build log says the same EXACT thing it said before.
It seems to me that CodeBlocks is saving my settings as I can see them from session to session, but it's not using them.
And I am happy to lay off of the non-CodeBlocks issue BUT it does not make sense to me that Cygwin would supply Mingw libs that you could not use with Cygwin.
NOTE: The Compiler you are changing the options on; MUST be the Compiler you are using to compile your project!
To check the CB Compiler name being used to compile your project do this.
"Project" -> "Build Options"
Check the selected compiler for each of the Target in the left hand pane.
To change Compiler Options:
"Settings" -> "Compiler and Debugger"
Pick the correct Compiler in the "Selected Compiler" pull down.
NOTE: Making this the default compiler is recommended!
Tim S.
Well under my Global compiler settings my Selected compiler says Cygwin GCC.
Auto-detect set the Compiler's installation directory to C:\Cygwin.
Global compiler settings->Toolchain executables->[tab]Program files->C compiler is C:\cygwin\bin\x86_64-w64-mingw32-gcc.exe .
So i tried starting from scratch.
I started a new project with a new name.
Main.c and rap.h are both in the C:\cygwin\home\eb\rap02 directory.
I have also entered 'C:\cygwin\home\eb\rap02' into Search directories->[tab]Compiler (under Global compiler settings).
The Selected compiler is still Cygwin GCC.
So now main.c contains '#include rap.h' and with Compiler logging set to Full command line my Build log says:
-------------- Build: Debug in rap02 ---------------
x86_64-w64-mingw32-gcc.exe -Wall -g -IC:/cygwin/home/eb/rap02 -c C:/cygwin/home/eb/rap02/main.c -o obj/Debug/main.o
cygwin warning:
MS-DOS style path detected: C:/cygwin/home/eb/rap02/main.c
Preferred POSIX equivalent is: /cygdrive/c/cygwin/home/eb/rap02/main.c
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
C:/cygwin/home/eb/rap02/main.c:10:17: fatal error: rap.h: No such file or directory
compilation terminated.
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings
OK you win. I'm switching back to non-cygwin headers/libs BUT this codeBlocks problem is still a problem!
Under Compiler Settings "Other Settings"
Check-mark "Explicitly add project top-level directly to compiler search dirs"
Note: The one above this might be more correct. I sometimes check mark them both.
Tim S.
Quote from: eb on January 20, 2012, 10:50:52 PM
OK you win. I'm switching back to non-cygwin headers/libs BUT this codeBlocks problem is still a problem!
Note: I was wrong about you using the Cygwin Compiler. You are trying to use the MinGW-64 compiler that was modified by the Cywgin group to work in the Cygwin environment. This is more likely to work.
But, a problem is that Code::Blocks does not work that well the Cygwin GCC as compared to MinGW GCC.
NOTE: A question I forgot to ask are you using Windows 64-bit OS; because I think the version of MinGW-64 you are using requires that to be true.
Tim S.
2 things:
1- I'm on XP-64bit and this program is for machines running 7-64bit.
2-I started another new project but in a new folder and CodeBlocks Search directories settings seemed to work fine. But when I came back to this project and switched back to Cygwin GCC the compiler is once again searching the directories of the previous project even though I have changed the default compiler and search directories.
Does this sound familiar?
Is this a bug?
edit: To re-cap:
Search directories:
C:\cygwin\home\eb\rap02
C:\cygwin\usr\include
yet Open #include file: 'rpc/clnt.h' opens "C:\rap02\include\glibc\rpc\rpc.h".
C:\rap02\include\glibc is the search directory from the previous project.
There is two major places to change the search directories.
The compiler settings and the project/task settings.
You likely have only fixed one of them.
NOTE: I had to add the Cygwin include folder to search list for rpc.h to be found.
You will need to change "C:\GreenApps\Cygwin1_7" to "C:\cygwin"
I added include search folder "C:\GreenApps\Cygwin1_7\usr\include\tirpc"
Edit: This might work also "$(TARGET_COMPILER_DIR)\usr\include\tirpc".
My build command. Updated because I saw two search folders removed one.
i686-pc-cygwin-gcc-4.exe -Wall -g -IC:/GreenApps/Cygwin1_7/usr/include/tirpc -c H:/SourceCode/Projects/test-i686-w64/main.c -o obj/Debug/main.o
i686-pc-cygwin-g++-4.exe -o bin/Debug/test-i686-w64.exe obj/Debug/main.o -ltirpc
Note: "H:/SourceCode/Projects/test-i686-w64" is my project folder.
Tim S.
I have decided that using the real Cygwin GCC likely works; but, trying to use the MinGW GCC versions are not possible for me to do. So, if you try the CygWin option I will help from time to time. But, the MinGW GCC is not worth any more effort on my part. Next post please include your Code::Blocks version; I am guessing it is 10.05.
Tim S.
Yes CodeBlocks 10.05
Windows XP Pro x64
Turns out both the compiler AND search directories problems are connected
For some reason now and then CodeBlocks ignores my Selected compiler and all of it's settings.
Currently no matter which Selected compiler I pick it will only use the Cygwin GCC settings.
I even set MinGW GCC as default, saved everything, closed/opened CodeBlocks, confirmed that MinGW GCC was my selected compiler, rebuilt the workspace, and it's still using my cygwin settings for Search directories and compilers. Even double checked to confirm that my selected compiler was still MinGW.
I also confirmed the location of the files.
fyi - the difference between my MinGW settings and my Cygwin settings is the MinGW Search directories are under my c:\MingW directory. My MinGW compilers are the ones in the c:\cygwin\bin directory with the default cygwin compiles.
YOU Verified the CB project is using the correct compiler for ALL targets in ALL projects!
Is this correct?
Tim S.
No, I'm saying that my compiler is doing this:
Quote-------------- Build: Release in rap00 ---------------
gcc-3.exe -Wall -O2 -IC:/cygwin/usr/include/tirpc -IC:/cygwin/usr/include -IC:/cygwin/home/eb/rap00 -IC:/cygwin/home/eb/rap00 -c C:/cygwin/home/eb/rap00/main.c -o obj/Release/main.o
g++-3.exe -o bin/Release/rap00.exe obj/Release/main.o C:/cygwin/lib/libtirpc.a C:/cygwin/Varkon_1.19D/sources/EX/lib/EXlib.a
Output size is 116.86 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
Where my code blocks settings say it should be doing something more like this:
Quote-------------- Build: Release in rap00 ---------------
mingw32-g++.exe -Wall -O2 -IC:/MinGW/lib/gcc/mingw32/4.6.2/include -IC:/mingw/include/bits -IC:/mingw/lib/gcc/mingw32/4.6.2/include/c++/parallel -IC:/mingw/home/eb/rap00 -IC:/mingw/home/eb/rap00 -c C:/mingw/home/eb/rap00/main.c -o obj/Release/main.o
mingw32-g++-3.exe -o bin/Release/rap00.exe obj/Release/main.o C:/MinGW/lib/librpcrt4.a C:/cygwin/Varkon_1.19D/sources/EX/lib/EXlib.a C:/MinGW/lib/libmingw32.a C:/MinGW/lib/gcc/mingw32/4.6.2/libstdc++.a
Output size is 116.86 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
And yes I know I'm mixing libraries and compilers again (I just caught that) and it will probably fail, but that's not the point.
@devs:
I'm thinking of adding the compiler name in the build log. What do you think about it?
How about this patch? Is it correct?
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 7807)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -1535,23 +1535,22 @@
if (action == baClean)
Action = _("Clean");
+ wxString compilerName(_("unknown"));
+ Compiler *compiler = CompilerFactory::GetCompiler(GetCurrentCompilerID(target));
+ if (compiler)
+ compilerName = compiler->GetName();
+
+#if wxCHECK_VERSION(2, 9, 0)
+ wxString targetName = target ? target->GetTitle().wx_str() : _("\"no target\"").wx_str();
+ wxString projectName = prj ? prj->GetTitle().wx_str() : _("\"no project\"").wx_str();
+#else
+ wxString targetName = target ? target->GetTitle().wx_str() : _("\"no target\"");
+ wxString projectName = prj ? prj->GetTitle().wx_str() : _("\"no project\"");
+#endif
+
wxString banner;
- banner.Printf(_("-------------- %s: %s in %s ---------------"),
- Action.wx_str(),
- target
- ? target->GetTitle().wx_str()
- #if wxCHECK_VERSION(2, 9, 0)
- : _("\"no target\"").wx_str(),
- #else
- : _("\"no target\""),
- #endif
- prj
- ? prj->GetTitle().wx_str()
- #if wxCHECK_VERSION(2, 9, 0)
- : _("\"no project\"").wx_str() );
- #else
- : _("\"no project\"") );
- #endif
+ banner.Printf(_("-------------- %s: %s in %s (compiler: %s)---------------"),
+ Action.wx_str(), targetName.wx_str(), projectName.wx_str(), compilerName.wx_str());
LogMessage(banner, cltNormal, ltAll, false, true);
}
Quote from: oBFusCATed on February 16, 2012, 09:11:46 PM
@devs:
I'm thinking of adding the compiler name in the build log. What do you think about it?
How about this patch? Is it correct?
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 7807)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -1535,23 +1535,22 @@
if (action == baClean)
Action = _("Clean");
+ wxString compilerName(_("unknown"));
+ Compiler *compiler = CompilerFactory::GetCompiler(GetCurrentCompilerID(target));
+ if (compiler)
+ compilerName = compiler->GetName();
+
+#if wxCHECK_VERSION(2, 9, 0)
+ wxString targetName = target ? target->GetTitle().wx_str() : _("\"no target\"").wx_str();
+ wxString projectName = prj ? prj->GetTitle().wx_str() : _("\"no project\"").wx_str();
+#else
+ wxString targetName = target ? target->GetTitle().wx_str() : _("\"no target\"");
+ wxString projectName = prj ? prj->GetTitle().wx_str() : _("\"no project\"");
+#endif
+
wxString banner;
- banner.Printf(_("-------------- %s: %s in %s ---------------"),
- Action.wx_str(),
- target
- ? target->GetTitle().wx_str()
- #if wxCHECK_VERSION(2, 9, 0)
- : _("\"no target\"").wx_str(),
- #else
- : _("\"no target\""),
- #endif
- prj
- ? prj->GetTitle().wx_str()
- #if wxCHECK_VERSION(2, 9, 0)
- : _("\"no project\"").wx_str() );
- #else
- : _("\"no project\"") );
- #endif
+ banner.Printf(_("-------------- %s: %s in %s (compiler: %s)---------------"),
+ Action.wx_str(), targetName.wx_str(), projectName.wx_str(), compilerName.wx_str());
LogMessage(banner, cltNormal, ltAll, false, true);
}
The last wx_str() of this line is necessary?
wxString targetName = target ? target->GetTitle().wx_str() : _("\"no target\"").wx_str();
Yes, in wx29 it is necessary.
Edit:
wxString targetName = target ? target->GetTitle() : wxString(_("\"no target\""));
wxString projectName = prj ? prj->GetTitle() : wxString(_("\"no project\""));
But this version works in both 2.8 and 2.9.
Quote from: oBFusCATed on February 16, 2012, 09:11:46 PM
How about this patch? Is it correct?
Looks good to me and will hopefully help us to trace user errors more easily.
BTW: The patch you've applied in the debugger branch concerning
CB_LIBRARY_ENVVAR should probably had made it into trunk first and then merged into the branch. Do you mind to apply this in trunk, too?
Quote from: MortenMacFly on February 17, 2012, 10:06:00 AM
Do you mind to apply this in trunk, too?
No, but I'm not sure if I can merge it properly. Can you do it for me?
Quote from: oBFusCATed on February 17, 2012, 10:20:16 AM
No, but I'm not sure if I can merge it properly. Can you do it for me?
Did it, but made a mistake in the log: It should read 7743 and not 6643. :-(
Unfortunately we don't have a
pre-revprop-change hook in place. :-(
So does this mean there is a new build I should try?
If you've not tried the nightly builds, then yes there is a new build, but I doubt it will help.
You have some configuration problem.
I just hijacked your topic and I'm sorry about it.
D'Oh!
btw - It seems that the settings under Project->Build options trump those under Compiler and debugger settings.
Things are starting to make sense now.
Thanks again Tim S.
Yes, also you can manage if the target or project options take precedence by using the Policy combo box.
@devs:
Another patch to improve debuggability:
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 7810)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -2366,9 +2366,19 @@
ProjectBuildTarget* tgt = prj->GetBuildTarget(tlist[x]);
if (!CompilerValid(tgt))
{
+ Compiler *compiler = CompilerFactory::GetCompiler(GetCurrentCompilerID(tgt));
+ wxString compilerName, compilerName2(wxT("unknown"));
+ if (compiler)
+ {
+ compilerName = wxT("(") + compiler->GetName() + wxT(") ");
+ compilerName2 = compiler->GetName();
+ }
wxString msg;
- msg.Printf(_T("\"%s - %s\": The compiler's setup is invalid so Code::Blocks cannot find/run the compiler. Probably the toolchain path within the compiler options is not setup correctly?! Skipping..."),
- prj->GetTitle().wx_str(), tlist[x].wx_str());
+ msg.Printf(_T("\"%s - %s\": The compiler's setup %sis invalid, so Code::Blocks cannot find/run the compiler.\n")
+ _T("Probably the toolchain path within the compiler options is not setup correctly?!\n")
+ _T("Goto Settings->Compiler and debugger...->Global compiler settings->%s->Toolchain executables\n")
+ _T("Skipping..."),
+ prj->GetTitle().wx_str(), tlist[x].wx_str(), compilerName.wx_str(), compilerName2.wx_str());
Manager::Get()->GetLogManager()->LogWarning(msg, m_PageIndex);
continue;
}
What do you think?
@devs: any comments for my patch?