src file won't compile anymore

[LMHmedchem]

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

[iiSoMeGuY 7x]

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...

[LMHmedchem]

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

[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.

[LMHmedchem]

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,

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

[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.

[Martin O]

I will try the small program

Oh, sorry I didn't see that you were going to try that.

[LMHmedchem]

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

[LMHmedchem]

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

[JohnW@Wessex]

Have you checked that all of your headers have guards?

[LMHmedchem]

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

[JohnW@Wessex]

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

[LMHmedchem]

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

[JohnW@Wessex]

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.

[LMHmedchem]

So this is one of the header files,

#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,

#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