Programming

It's been a long time since I fought this battle ....

I have an application written in c++, very much written in objects, etc. I have a makefile that compiles and links the application.

I am running this on a Linux (Fedora 20) platform and all works just fine, but when I compile and link in a cygwin environment on a Windows platform, the application fails during initialization. I suspect I have an elaboration problem and simply don't know/remember how to manage elaboration order in this c++ environment.

Can anybody give me some pointers? Documentation to read? Experiences?

Thanks.

Bill Lee

Maybe put a log to syserr in the constructors of your objects, so you can see what is different when it fails?

Comparison between GNAT and C/C++ Compilation Models - GNAT User's Guide for Native Platforms / Unix and Windows

I wouldn't log to syserr using C++ streams - that could impact constructor order.

I'd recommend only C-style IO and the use of "fprintf( stderr, ... )". Don't even do any additional informational-style calls, for example if the objects have some equivalent of Java's tostring() method. No C++ at all.

If you're trying to run down problems C++ ordering problems, don't make it more complex with debugging code that you won't even compile much less run in a production version of the software.

Yes, exactly -- you can make them print in debug mode, perhaps defined by an env. var, not using any objects, just C-isms.

Code:

int global_debug = -1 ; // In global space
 .
 .
 .
// top of constructor for class XXXXX
if ( global_debug < 0 ){
  if ( NULL == getenv( "DEBUG" )){
    global_debug = 0 ;
  } else {
    global_debug = 1 ;
  }
}
if ( global_debug ){
  fputs( "\nObject XXXXX Constructor start.\n", stderr );
}

But then you'd be distributing code with debug strings in it - might not be something you'd want to do, given what developers can put in debug strings.

Nor may you want customers to be able to run in debug mode. Or maybe you DO want that.

Just be aware of what's in that binary and what it can do.

Fun problem for those with too much time on their hands (or a requirement to do it): come up with a secure way to modify debug level while the process is still running.

Simple: Put debug level in a file and 'mmap()' the file. The controlling variable is in the VM space of the process but anyone with write permission can change it. To use a binary int, you need an app to change the value. Note that if the file is on NFS, values set elsewhere are not seen unless the file status is read, like with 'ls -l', on the target machine.

have you got GDB on cygwin? if it creates a core file you can use it to find where it fails?

or strace this can often give good clues too.