bin.3.e32 - really confusing

Moderator: dar

bin.3.e32 - really confusing

Postby nickoppen » Thu Apr 14, 2016 11:38 am

I'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?
Sharing is what makes the internet Great!
User avatar
Posts: 266
Joined: Mon Dec 17, 2012 3:21 am
Location: Sydney NSW, Australia

Re: bin.3.e32 - really confusing

Postby jar » Thu Apr 14, 2016 4:26 pm


Although I'm not driving the ship, it's going to change soon. Having used the new compilation for COPRTHR 2.0, I can say it feels more familiar now. The --dump-bin was there in 1.6 to use in the COPRTHR API. It wasn't used directly for the OpenCL/STDCL API OpenCL binary, which required additional compilation and linking, IIRC.
User avatar
Posts: 295
Joined: Mon Dec 17, 2012 3:27 am

Return to OpenCL

Who is online

Users browsing this forum: No registered users and 2 guests