bin.3.e32 - really confusing
Posted: Thu Apr 14, 2016 11:38 amI've been struggling with my coprthr/mpi program.
The call to coprthr_cc_read_bin was returning a valid pointer but coprthr_getsym was returning 0xffffffff.
I was attempting to compile the cl file using the command line (rather than Code::Blocks) and I noticed a bin.3.e32 file in the home directory which was weird because I was directing my output to bin/Debug. I poked it with clnm and nm and those commands responded in the same way as they did for the bin.3.e32 files in the examples.
Copying my new bin.3.e32 to the bin/Debug directory all of a sudden my program worked!
This is really confusing. All I can think is that the bin.3.e32 is a side effect due to the --dump-bin switch??? Also, the .o file generated by the compiler is actually ignored other than as a time marker for the make command?
I've searched the documentation thinking that I missed something but I can't find a reference to this behaviour anywhere. Is this a "will change in a future release" feature or an intended outcome?
The call to coprthr_cc_read_bin was returning a valid pointer but coprthr_getsym was returning 0xffffffff.
I was attempting to compile the cl file using the command line (rather than Code::Blocks) and I noticed a bin.3.e32 file in the home directory which was weird because I was directing my output to bin/Debug. I poked it with clnm and nm and those commands responded in the same way as they did for the bin.3.e32 files in the examples.
Copying my new bin.3.e32 to the bin/Debug directory all of a sudden my program worked!
This is really confusing. All I can think is that the bin.3.e32 is a side effect due to the --dump-bin switch??? Also, the .o file generated by the compiler is actually ignored other than as a time marker for the make command?
I've searched the documentation thinking that I missed something but I can't find a reference to this behaviour anywhere. Is this a "will change in a future release" feature or an intended outcome?