src file won't compile anymore

Printable View

May 24th, 2011, 07:10 PM
LMHmedchem

src file won't compile, compiler hangs with no errors

I have some code that I have been working on for a while, and suddenly it won't compile anymore. There are no errors to report because the compiler just hangs and sits forever without creating the object. I have gone back several versions and am trying to confirm my most recent version that I can still get to compile. I can do a diff and try to find the issue, but I'm not even sure where to look at this point.

What kinds of things could cause a compiler to hand without throwing some kind of error?

LMHmedchem
May 24th, 2011, 07:56 PM
iiSoMeGuY 7x

Re: src file won't compile anymore

a non-ending program?
not really sure without looking at the code, but from what you're saying, if the compiler just "sits forever" its probably because you never ended the program...
May 24th, 2011, 09:35 PM
LMHmedchem

Re: src file won't compile anymore

This is part of a large program that I have been working on all week. There are about functions in the src file, but all of them have been working fine. I have walked back quite a bit and I have it compiling, but it is taking about 5 minutes to compile. I worked on this for days, and it has never taken more than two or three seconds to compile.

As far as I can check, everything still works, but it makes no sense that this file is suddenly taking longer to compile that it took for the entire 50 file project to compile and build a couple of days ago.

Is it possible that something is wrong with the compiler?

LMHmedchem
May 25th, 2011, 04:28 AM
olivthill2

Re: src file won't compile anymore

What is the name and version of your compiler?

I have heard of problems like that in the past with MSC precompiled headers, and the solution was to recreate them. Otherwise, I don't know. I use mingw and never had that kind of problems.

Edit : I read now your other message and I see you use mingw too. You said you had problems with crt2.o and libraries. Do you still have them?

Edit Edit : Now, I am thinking of a circular reference. An object would refer to a function in another object who would refer to a function in another object, etc., and the linker would not be able to find the right function.

Or maybe there is a loop caused by the path to a directory for the place of something, e.g. libraries or other things, and that path would be a link/shortcut to another place which would redirect to the initial place, and thus making a circular reference.

And since you reinstall your compiler, could you try it with a simple project, to validate your new installation.
May 25th, 2011, 10:03 AM
LMHmedchem

Re: src file won't compile anymore

Quote:

Originally Posted by olivthill2

What is the name and version of your compiler?

I have heard of problems like that in the past with MSC precompiled headers, and the solution was to recreate them. Otherwise, I don't know. I use mingw and never had that kind of problems.

Edit : I read now your other message and I see you use mingw too. You said you had problems with crt2.o and libraries. Do you still have them?

Edit Edit : Now, I am thinking of a circular reference. An object would refer to a function in another object who would refer to a function in another object, etc., and the linker would not be able to find the right function.

Or maybe there is a loop caused by the path to a directory for the place of something, e.g. libraries or other things, and that path would be a link/shortcut to another place which would redirect to the initial place, and thus making a circular reference.

And since you reinstall your compiler, could you try it with a simple project, to validate your new installation.

Nothing is working at the moment. I am just starting to try to narrow the issue down. I have compiled this identical code on this setup, and on another one, with no issues, or 3+ minutes to compile a single src file. That's why I reinstalled. I have had some issues with cygwin staying stable over time and have had to re-install before.

I will try the small program, but I think the issue is linking to the std lib in my make. It looks like something may have changed with gcc, which has certainly happened before. That is one reason I tend to stick to 3.4, since it's closed (in theory).

I have the following packages installed,

Code:

binutils 2.20.51-2 gcc-core 3.4.4-3 gcc-g++ 3.4.4-3 gcc-g77 3.4.4-3 gcc-mingw-core 20050522-3 gcc-mingw-g++ 20050522-3 gcc-mingw-g77 20050522-3 libgcc1 4.3.4-4 libstdc++6 4.3.4-4 libstdc++6-devel 4.3.4-4 mingw-runtime 3.18-1 make

Do you see anything that I'm missing. The cygwin package manager is pretty good, so I would be surprised if a re-install removed some required dependency, but anything is possible I guess.

I would guess that it is more likely that the problem is having the version 4 libs, which may not be compatible with gcc3. The only options are 4.3.4 or 4.3.3. I will check an older machine and see if I can figure out what is different.

LMHmedchem
May 25th, 2011, 10:39 AM
Martin O

Re: src file won't compile anymore

Does a simple hello world program compile? If yes then use divide & conquer to narrow down why hello world works but your entire app doesnt. If hello world doesnt work then you have a much simpler test case you can use to troubleshoot your compiler problem.

When I say 'use divide & conquer' I mean, comment out large chunks of code until the problem goes away, then slowly put back the chunks until you can narrow down the problem.
May 25th, 2011, 10:40 AM
Martin O

Re: src file won't compile anymore

Quote:

Originally Posted by LMHmedchem

I will try the small program

Oh, sorry I didn't see that you were going to try that.
May 25th, 2011, 10:50 AM
LMHmedchem

Re: src file won't compile anymore

Quote:

Originally Posted by Martin O

Does a simple hello world program compile? If yes then use divide & conquer to narrow down why hello world works but your entire app doesnt. If hello world doesnt work then you have a much simpler test case you can use to troubleshoot your compiler problem.

When I say 'use divide & conquer' I mean, comment out large chunks of code until the problem goes away, then slowly put back the chunks until you can narrow down the problem.

With the new problem, after the re-install, the issue is with the linker. The code all compiles (the one src file is still very slow), but I get the errors above when the linker tries to put the whole thing together. That is why I think the problem is with the lib.

LMHmedchem
May 25th, 2011, 10:04 PM
LMHmedchem

Re: src file won't compile anymore

After having fixed the compiler issue, I am back to my src file that takes 3+ minutes to compile, and used to take 2-3 seconds. I have commented out all of the executable code in the functions in the src file, and this makes no change in the compile time. There must be a problem in one of the header files, but it is hard to check that since commenting out the includes invokes compiler errors in some cases.

I'm not even sure what I am looking for at this point that would cause a bunch of functions with no executable code to take 3 minutes to compile.

LMHmedchem
May 26th, 2011, 07:25 AM
JohnW@Wessex

Re: src file won't compile anymore

Have you checked that all of your headers have guards?
May 26th, 2011, 09:22 AM
LMHmedchem

Re: src file won't compile anymore

Quote:

Originally Posted by JohnW@Wessex

Have you checked that all of your headers have guards?

I'm not sure what that means.

I think I have narrowed it down to a function that loads a map of objects. This probably doesn't belong in a header file. The strange thing is that I don't remember any long compile times when I was working on that part of the code. Is it possible that it could take 3min to compile? That doesn't seem right. The map has less than 150 entries and the objects are pretty simple holding two ints and a short string.

I can post that part of the code if anyone wants to see it.

LMHmedchem
May 26th, 2011, 09:45 AM
JohnW@Wessex

Re: src file won't compile anymore

Quote:

Originally Posted by LMHmedchem

I'm not sure what that means.

They ensure that the header is only included once.

#ifndef THIS_HEADER_XXX
#define THIS_HEADER_XXX

// The rest of the header.

#endif
May 26th, 2011, 10:07 AM
LMHmedchem

Re: src file won't compile anymore

Quote:

Originally Posted by JohnW@Wessex

They ensure that the header is only included once.

#ifndef THIS_HEADER_XXX
#define THIS_HEADER_XXX

// The rest of the header.

#endif

Do you mean for lib includes like #include <sstream>, or for everything? I'm not sure how this applies to definitions that need to be used by multiple src files.

LMHmedchem
May 26th, 2011, 10:12 AM
JohnW@Wessex

Re: src file won't compile anymore

Quote:

Originally Posted by LMHmedchem

Do you mean for lib includes like #include <sstream>, or for everything?

The standard headers will already have them. All of your headers should have them too. Without them the compiler may include a large header file multiple times or worse, get itself into an infinite '#include' loop.
May 26th, 2011, 10:38 AM
LMHmedchem

1 Attachment(s)

Re: src file won't compile anymore

So this is one of the header files,

Code:

#define igMaxSets 50 #define maxNVXc 200 class desVal { public : desVal(const int desPos_P, const int HdesPos_P, const std::string& igrp_mark_P) : desPos(desPos_P), HdesPos(HdesPos_P), igrp_mark(igrp_mark_P) { } int desPos, HdesPos; std::string igrp_mark; }; extern int iglk_ami_typ[maxNVXc], iglk_tam_typ[maxNVXc], iglk_sam_typ[maxNVXc], iglk_gua_typ[maxNVXc], iglk_acd_typ[maxNVXc], iglk_est_typ[maxNVXc], iglk_cbm_typ[maxNVXc], iglk_ani_typ[maxNVXc], iglk_dsp_typ[maxNVXc], iglk_hyd_typ[maxNVXc] extern void load_igrp_maps(); extern int lookup_igrp_descriptor_position(const std::string &igrp, const int &AT, int &desPos, int &HdesPos, std::string &igrp_mark);

I should change this to,

Code:

#ifndef IGROUP_MAPS #define IGROUP_MAPS #define igMaxSets 50 #define maxNVXc 200 class desVal { public : desVal(const int desPos_P, const int HdesPos_P, const std::string& igrp_mark_P) : desPos(desPos_P), HdesPos(HdesPos_P), igrp_mark(igrp_mark_P) { } int desPos, HdesPos; std::string igrp_mark; }; extern int iglk_ami_typ[maxNVXc], iglk_tam_typ[maxNVXc], iglk_sam_typ[maxNVXc], iglk_gua_typ[maxNVXc], iglk_acd_typ[maxNVXc], iglk_est_typ[maxNVXc], iglk_cbm_typ[maxNVXc], iglk_ani_typ[maxNVXc], iglk_dsp_typ[maxNVXc], iglk_hyd_typ[maxNVXc] extern void load_igrp_maps(); extern int lookup_igrp_descriptor_position(const std::string &igrp, const int &AT, int &desPos, int &HdesPos, std::string &igrp_mark); #endif

I have done that for file I am having problems with, and it still takes forever to compile. I have attached a .zip with the src file and header. I have rearranged this some so the the function and header are more properly separated into a src and .h file. I have also isolated this from some other code to confirm that this is what is causing the delay. It's not a disaster if it takes time to compile, since the map is static and won't get changed very often.

I am mostly concerned that the code may not be well formed and this is causing the compile delay. If it's just a code structure that takes a long time to compile, I will live with it for now.

LMHmedchem
May 26th, 2011, 01:05 PM
Martin O

Re: src file won't compile anymore

Quote:

Originally Posted by LMHmedchem

I have attached a .zip with the src file and header.

It doesn't compile:

Code:

$ gcc igroup_maps.cpp In file included from igroup_maps.cpp:4: igroup_maps.h:27: error: expected init-declarator before "extern" igroup_maps.h:27: error: expected `,' or `;' before "extern"

Invest an extra 2 seconds of effort & actually compile the code before asking other people to troubleshoot the slow compile problem.
May 26th, 2011, 03:09 PM
LMHmedchem

Re: src file won't compile anymore

Quote:

Originally Posted by Martin O

It doesn't compile:

Code:

$ gcc igroup_maps.cpp In file included from igroup_maps.cpp:4: igroup_maps.h:27: error: expected init-declarator before "extern" igroup_maps.h:27: error: expected `,' or `;' before "extern"

Invest an extra 2 seconds of effort & actually compile the code before asking other people to troubleshoot the slow compile problem.

This does compile, I can post the compiled object if you want it. After looking at the file I posted in the .zip, there is a missing semicolon at the end of line 25. I must have missed that on my last edit. Other than that, it should be fine.

LMHmedchem
May 26th, 2011, 03:14 PM
Paul McKenzie

Re: src file won't compile anymore

Quote:

Originally Posted by LMHmedchem

I will try the small program, but I think the issue is linking to the std lib in my make.

Compiling is not linking.

To see if it is a slow compile, then you could use the -c switch to just compile the source code instead of compiling and linking. The linker used is ld (as far as I remember), not gcc (which is just a compiler, not a linker).

Regards,

Paul McKenzie
May 26th, 2011, 03:25 PM
Martin O

Re: src file won't compile anymore

Quote:

Originally Posted by LMHmedchem

This does compile
....
After looking at the file I posted in the .zip, there is a missing semicolon at the end of line 25.

Which....makes it not compile.

At any rate, no problems compiling here:

Code:

$ g++ -dumpversion 3.4.4 $ date Thu May 26 15:18:41 CDT 2011 $ g++ -c igroup_maps.cpp $ date Thu May 26 15:18:46 CDT 2011

See how I copy/pasted the actual commands I ran in my command prompt? You should do that, otherwise everyone has to keep guessing.
May 26th, 2011, 05:39 PM
LMHmedchem

Re: src file won't compile anymore

Quote:

Originally Posted by Martin O

Which....makes it not compile.

At any rate, no problems compiling here:

For some reason, I wasn't expecting folks to try to compile this. I just though someone might take a look at it and see if there was something obvious that was visable.

Well this is odd, if I compile from the shell with no flags,

Code:

$ time g++ -c igroup_maps.cpp real 0m2.078s user 0m0.700s sys 0m0.326s

it compiles quickly. When I compile just that object from my make file,

Code:

$ time make ver=igrp -f MAKE_11-04-29.mingw client g++ -mno-cygwin -O2 -DWINVER -DDATESTR=\"0.11.05.26\" -DRELEASEVERSION -DLICNUM=0 -DV ERNUM=5 -c -o bld_CYGWIN_NT-5.1_g34_1.7.i686/igroup_maps.o src/igroup_maps.cpp real 3m15.968s user 3m14.471s sys 0m0.926s

it takes 3+ min. A few seconds of this is the linker, but I can see when the linker starts and prints its output and it is only a few seconds. The make file is passing allot more flags and such, so I decided to add some of them to the shell command. It appears that the issue is using the -O2 optimize level. If I complie with -O2,

Code:

$ time g++ -O2 -c igroup_maps.cpp real 3m14.656s user 3m13.872s sys 0m0.451s

If I use -O0 in the make or shell, then I am back to 2 seconds to compile.

I know that using various levels of optimize can increase the compile time, but I didn't think it would increase by a factor of 100. This underscores the comment by Martin about posting the exact compile command, so thanks for that pointer.

I am still a bit mystified as to why I didn't notice this when I was writing the code, since I have used the same make for quite a while. That had me convinced that the slowdown was the result of a recent change in the code, and I am not yet un-convinced. I would like to know what people think about this being simple an issue of using optimize, or if I should be looking for some other underlying issue.

LMHmedchem
May 26th, 2011, 09:45 PM
Martin O

Re: src file won't compile anymore

I got the same slowness when I added the -O2 option. It's the iniIgrpDesMap function that is causing the slow compile time. I think you can improve compile time by adding to your map like this:

Code:

igrpDesMap["AM_16"] = desVal(-1,-1, "NNNN");

instead of this:

Code:

igrpDesMap.insert(pair<string,desVal>("AM_16", desVal(-1,-1, "NNNN") ));

I tested a cut down version of the program & it improved compile time-- adding the first 17 entries went from roughly .8ms to .5ms.
May 26th, 2011, 11:09 PM
LMHmedchem

Re: src file won't compile anymore

Thanks, I'll try that. Do you think that the issue is the use of insert() or the use of pair?

LMHmedchem

I'm getting the following compile error,

Code:

$ time make ver=igrp -f MAKE_11-04-29.mingw client g++ -mno-cygwin -O2 -DWINVER -DDATESTR=\"0.11.05.27\" -DRELEASEVERSION -DLICNUM=0 -DV ERNUM=5 -c -o bld_CYGWIN_NT-5.1_g34_1.7.i686/igroup_maps.o src/igroup_maps.cpp /usr/lib/gcc/i686-pc-mingw32/3.4.4/include/c++/bits/stl_map.h: In member function `_T p& std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with _Key = std::s tring, _Tp = desVal, _Compare = std::less<std::string>, _Alloc = std::allocator<std:: pair<const std::string, desVal> >]': src/igroup_maps.cpp:189: instantiated from here /usr/lib/gcc/i686-pc-mingw32/3.4.4/include/c++/bits/stl_map.h:339: error: no matching function for call to `desVal::desVal()' src/igroup_maps.cpp:189: note: candidates are: desVal::desVal(const desVal&) src/igroup_maps.h:13: note: desVal::desVal(int, int, const std::string&) make: *** [bld_CYGWIN_NT-5.1_g34_1.7.i686/igroup_maps.o] Error 1

It doesn't seem to like the call to create the object.
May 26th, 2011, 11:24 PM
Martin O

Re: src file won't compile anymore

Oh yeah, I forgot to mention I also had to add a no-args constructor to desVal:

Code:

class desVal { .. desVal() : desPos(0), HdesPos(0) { } ... };

I thought it might be slower because of using 'pair'. I know that templates are expanded at compile time...maybe template expansion plus optimization caused the compiler to work a lot harder. Just a guess.
May 26th, 2011, 11:37 PM
LMHmedchem

Re: src file won't compile anymore

Quote:

Originally Posted by Martin O

Oh yeah, I forgot to mention I also had to add a no-args constructor to desVal:

Code:

class desVal { .. desVal() : desPos(0), HdesPos(0) { } ... };

I thought it might be slower because of using 'pair'. I know that templates are expanded at compile time...maybe template expansion plus optimization caused the compiler to work a lot harder. Just a guess.

Where do I add this? Does it take the place of the current constructor?

This works and compiles in just a few seconds.

Code:

class desVal { public : desVal() : desPos(0), HdesPos(0) { } desVal(const int desPos_P, const int HdesPos_P, const std::string& igrp_mark_P) : desPos(desPos_P), HdesPos(HdesPos_P), igrp_mark(igrp_mark_P) { } int desPos, HdesPos; std::string igrp_mark; };

What is the need for the second constructor? It is curious that it should need more than one, and it seems to need to use both if it is going to load the proper values to the object data members.

...anyway, the format for the map is more compact this way anyway, and it will probably work a bit faster without the need to invoke pair and insert. It is still strange that I never noticed the long compile times while I was working on it.

LMHmedchem