[Linux] Error compiling the copystrings (Unix) on Ubuntu 5.10

[Michael]

Hello,

I got an error when compiling the contr. plugins workspace. I am using C::B rev2185.

copystrings.cpp:10:17 error: calling fdopen: Bad file descriptor

The problem is located here:

Code

#include "sdk.h"

C::B itself compiled fine.

I have also tried to get a new sdk.h from SVN, but got the same error.

Best wishes,
Michael

[killerbot]

damn damn, I think I might have screwed this one up. All the other plug-ins build ok ??

Last friday I changed sdk.h, but everything kept on building, yesterday I cleaned up copystrings, I have the feeling, something was wrong there.

[Michael]

Hello,

I will give a try to the others and then post here. I have just stopped at the error.

Best wishes,
Michael

[killerbot]

although it should not have anything to do with it : try <sdk.h> ??

On windows everythings still builds ok, so that's one thing.
Another thing to try :
comment out the ifdef CB_PRECOMP, sdk.h the else and endif, just to see if copystrings compiles.

In the meantime I am rebooting and switching to linux

[EDIT] : in linux ... and building .....

[killerbot]

Woops : other problems,
I have error in the building of codestat :
Seems Zlika's commit does not work on linux.
codestatconfig.cpp -> will fix them once I am back in windows.

[EDIT] : FIX

just add in that cpp file :
#include "manager.h"
#include "configmanager.h"

There's more to adjust to have the includes "clean and correct", but I will adjust that later this week. Just by adding these 2 lines, we are up and running again.

[Michael]

although it should not have anything to do with it : try <sdk.h> ??

Does not work.

comment out the ifdef CB_PRECOMP, sdk.h the else and endif, just to see if copystrings compiles.

This works. copystrings project builds fine.

I have also tried a clean and then a build, but does not solve the problem. Strange, because I have built without problems the .deb package for revision2215 :?.

Best wishes,
Michael

[Michael]

Woops : other problems,
I have error in the building of codestat :
Seems Zlika's commit does not work on linux.
codestatconfig.cpp -> will fix them once I am back in windows.

codestat builds here. I have tried a re-build and I got 0 errors and 0 warnings. Anyway, I have remarked a typo:

------- Build: default in Code statitstics (Unix) -------

Best wishes,
Michael

[killerbot]

very weird. I could build on linux, except from the codestats problem. Are you on rev 2216 on linux ?? Since rev 2216 was the change to codestats.

[Michael]

very weird. I could build on linux, except from the codestats problem. Are you on rev 2216 on linux ?? Since rev 2216 was the change to codestats.

Yes, I am in rev2216. For me I can build all, except the copystrings project. If I comment out the lines you told me, it compiles fine.

Best wishes,
Michael

[killerbot]

so it seems sdk.h is still correct (relief ...), why can it be used in the other plug-ins and not in copystrings

By the way, copystrings did not compile on my system, meaning it is NOT included in the build system.
I use command line : make --> and indeed ther's no makefile in the copystrings, so it is left out. How did you build it ?? Are the settings for the copystrings project ok then

[killerbot]

info : gcc : 4.0.2  (oh yeah : I am on suse) .

[Michael]

so it seems sdk.h is still correct (relief ...), why can it be used in the other plug-ins and not in copystrings

By the way, copystrings did not compile on my system, meaning it is NOT included in the build system.
I use command line : make --> and indeed ther's no makefile in the copystrings, so it is left out. How did you build it ?? Are the settings for the copystrings project ok then

I avoid to compile C::B with make, because it takes so much on my poor Pentium III 500MHz. To compile C::B I use CodeBlocks-unix.cbp and to compile contr. plugins ContribPlugins-unix.workspace. The GCC is the same (IIRC).

May be you should update the CodeBlocks-unix.cbp?

Best wishes,
Michael

[killerbot]

totally different things seem to happen with :
 1) make build
 2) cbp build
I think I recall something that the pch are not interchangeable between 1) and 2).
But there seem to be more differences, since we both have same compiler (and version of compiler), my make build couldn't compile the codestat, and your without a problem.

[killerbot]

all righty :
 - just to allow everyone to build without error, this is what I am gonna do for now :
a) copystrings.cpp : uncomment the lines as described above (I still don't get it why it wouldn't work)
b) codestatconfig.cpp : add the 2 includes

--> that will be the next revision, and the nightly build will be based on that one.

[Michael]

totally different things seem to happen with :
 1) make build
 2) cbp build
I think I recall something that the pch are not interchangeable between 1) and 2).
But there seem to be more differences, since we both have same compiler (and version of compiler), my make build couldn't compile the codestat, and your without a problem.

Yes, there is a "problem" with PCH. I have posted it here.

Practically, with make you will have a PCH file. Instead with the cbp a directory with inside the PCH file.

Best wishes,
Michael

[Michael]

--> that will be the next revision, and the nightly build will be based on that one.

Could you commit them so that I will build another .deb package?

Thank you .

Best wishes,
Michael

[killerbot]

commited

[Michael]

commited

Great. Thanks .

Best wishes,
Michael

[killerbot]

could you try with out the updates (or uncomment the lines in copystrings.cpp) and remove the following line from your copystring-unix.cbp :
         <Add option='-include &quot;sdk.h&quot;' />

[EDIT] : Question : why do we need that option ??

Thanks

[Michael]

could you try with out the updates (or uncomment the lines in copystrings.cpp) and remove the following line from your copystring-unix.cbp :
         <Add option='-include &quot;sdk.h&quot;' />

Ok. I finish to build C::B and .deb package and I will give it a try .

Best wishes,
Michael

[killerbot]

could you try with out the updates (or uncomment the lines in copystrings.cpp) and remove the following line from your copystring-unix.cbp :
         <Add option='-include &quot;sdk.h&quot;' />

Ok. I finish to build C::B and .deb package and I will give it a try .

Best wishes,
Michael

any news on this ??

[Michael]

any news on this ??

Sorry, I am a bit late in my report :oops:.

What I have is the following:

• Delete SDK and wxSmith PCH
• Modify the copystring-unix.cbp as suggested
• Modify the copystring.cbp as suggested
• Build C::B
• Build Contr. plugins

Copystrings project compiles fine .

Best wishes,
Michael

[killerbot]

So the code seems to be ok (heheh       ) , I will uncomment it again this evening.
And I will adjust that one unix cbp file.
@Yiannis, Thomas : do you know why we needed that include sdk.h compiler option in the unix cbp ??

[thomas]

We don't need it if the #include in the source file is uncommented and not disabled by a preprocessor directive. I don't know who put it there or why.

It does the exact same thing as #include (except for a neglegible difference in search path order).

[killerbot]

the thing is, if that directive is there, and the code also has the include (this latter case is IMHO the correct way) we get errors (as described in the start of this topic).
Yiannis told me that such an error also shows up if you include "sdk.h" in a header file, but in this situation that was not the case.
I noticed other plug-ins also have this directive, well I'll adjust them when I clean the the headers includes of those plug-ins.

[killerbot]

committed : rev 2220

[thomas]

But it is really the exact same thing (except that the CWD is searched first, which does not matter in this case, as it is identical with the source file's directory):

Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the #include "..." search chain as normal.