Building on Debian Stretch fails about cl3 HOT 4 CLOSED

@vmx this is a strange one.

clSetMemObjectDestructorAPPLE is called by set_mem_object_destructor_apple which is defined in ext.rs where it is preceded by #[inline]. I had similar link issues during development which was fixed for me by preceding set_mem_object_destructor_apple with #[inline].

Please can you check your build options? Is there a way that #[inline] is being ignored.

I could add a feature like cl_khr_icd to guard set_mem_object_destructor_apple. clSetMemObjectDestructorAPPLE is not guarded in the OpenCL header file, however, it is obviously an Apple specific feature, so it would make sense.

from cl3.

That was an interesting one. I would say the CI instance did the right thing, the other systems didn't.

The difference is that on CI the link-dead-code option was set. This leads to no dead code elimination. By default the current code links to the clSetMemObjectDestructorAPPLE synbol, which isn't part of my OpenCL.so. Neither on the CI instance one, nor on my local one. The reason why it did compile though is, that I never called this function, hence it was removed during compilation.

I can reproduce it reliably locally when running RUSTFLAGS='-C link-dead-code' cargo test.

My suggested fix would be to put it behind a feature flag, so that it isn't compiled by default. I also think that testing a library with RUSTFLAGS=-C link-dead-code set makes a lot of sense to catch those problems, which lead to hard to track down bug reports like this one.

from cl3.

Thank you for your investigations Volker. It's good to know that link-dead-code was responsible.

However, I've followed your advice and added a new build feature: cl_apple_setmemobjectdestructor to protect it.
This corresponds to the cl_APPLE_SetMemObjectDestructor macro in cl_ext.h.

from cl3.

I've tested the latest released version of opencl3 with the default features, this is no longer an issue. Thanks for the quick fix!

from cl3.