<NabanitaDash[m]>
https://github.com/mlpack/mlpack/pull/3140 I don't understand why I am getting errors in all other testcases excluding the one I just added. In my system, I don't get any error but the CI shows those.
rcurtin[m] has joined #mlpack
<rcurtin[m]>
Nabanita Dash: what have you tried to debug the issue? have you tried to reproduce these problems locally?
<NabanitaDash[m]>
No, I haven't tried reproducing these locally. I will do that.
<rcurtin[m]>
zoq: can you check what version of stb is installed on polar?
<zoq[m]1>
zoq[m]1: We can update the base image, if necessary.
baracurda has quit [Ping timeout: 276 seconds]
baracurda has joined #mlpack
<rcurtin[m]>
shrit: so it's definitely a versioning issue in `stb_image_write.h`. the version on Ubuntu 20.04 has a couple functions that *aren't* marked as `static`, thus causing the linker issue. so we have a handful of choices:
<rcurtin[m]>
1) update the version of STB on the memory check docker image, then just tell users to update STB if they encounter the same issue (even though Ubuntu 20.04's version is too old)
<rcurtin[m]>
2) modify our CMake configuration to detect the version of stb_image_write.h and require a new enough version... but the problem here is that the versioning of stb seems to be arbitrary, is different for every file, and we'd have to detect it based on some random regexes that would be brittle if the maintainer ever changed the format
<rcurtin[m]>
3. add a check to CMake that looks for one of the function names that the build is currently failing on and makes sure that function is marked `static`, otherwise it issues a CMake error saying the version of `stb_image_write.h` is too old (basically just a simple grep but with CMake)
<rcurtin[m]>
maybe there are some other options... personally I might lean towards (1) or (3)... I think (2) would set us up for some ugly maintenance in the future, and I don't know how commonly a user might encounter this issue
<zoq[m]1>
You could also add a simple test program and try to build that, this is basically how the c++11 test works.
<zoq[m]1>
s/test/check/
<rcurtin[m]>
yeah, that's an option too; shrit if you want I can whip up a simple test program
<shrit[m]>
rcurtin: I am not sure if I understand the test program idea correctly, but otherwise I think the best option we have is 3
<shrit[m]>
the main issue for users is that, not all of them are going to open an issue in github or understand that they have to update STB, this means that we are going to lose users for a simple compilation error
<shrit[m]>
I think that option 3 is going to tell users that they need a new version of stb so they complete the task by themselves
<shrit[m]>
unless if option program test is going to improve the situtation
<shrit[m]>
Also I have no idea if it is possible to check if a function is static using CMake
<rcurtin[m]>
oh, you would just use a regex to grep for the signature including the word `static`
<rcurtin[m]>
I think zoq 's idea of test compilation here may be the better idea---if you make a very simple program with two .cpp files, then include stb_image_write.h from both .cpp files and link them both into one shared object, that will fail if the version of STB is too old