Building on Debian Stretch fails

[vmx]

The CI I'm running on is using Debain Stretch as base system. There I get linker errors like this when I run cargo test.

/root/cl3/target/debug/deps/cl3-5580034d3b79b1c6.3heyk7dg5tpkvm6y.rcgu.o: In function `cl3::ext::set_mem_object_destructor_apple':
          /root/cl3/src/ext.rs:40: undefined reference to `clSetMemObjectDestructorAPPLE'
          collect2: error: ld returned 1 exit status

This was introduced recently by adding the extensions. It seems to be a problem with the environment. It works for me on two other, completely different systems (one of them is also Debian, though a newer version.

I even copied over the /usr/lib/x86_64-linux-gnu/libOpenCL.so from a machine where it works, to the machine where it doesn't. It's still the same error.

I'm still looking into this. I'm just opening this issue in hope that @kenba has seen this before and might have an idea.

[kenba]

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

[vmx]

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.

[kenba]

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.

[vmx]

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