@nprofile1q... @nprofile1q... @nprofile1q... a variation of this is when you fix a bug in a 3rdparty library, and you want to test the change before submitting it upstream. Except due to complexities in the build system you end up testing the old code and not the new one. Especially if the build requires applying a patch queue, where you've carefully added all the patches, but forgot to actually update the series file/.spec file/etc.
(The code was all fine and tested with unit tests in a proper git repo, but that is not always what the build system consumes).

A good way to ensure you are running the right code is to define a new function temporarily, and explicitly call that from the main application. Then you get a build error if you have the wrong dependency.
Also include a unique string in that function (not necessarily as a log statement, maybe the library isn't allowed to log), and check for the string in the built binary with `strings -a`.