When people try to build and test their own version of mtr, if they try to execute ./mtr directly from the building dir, they may ignore that the wrong mtr-packet binary is invoked if they have already installed another version of mtr don't have environment variable MTR_PACKET set, which potentially leads to wrong result.
It would be nice if there's a description on such behavior in README file, or make mtr try to load mtr-packet from current directory first.
This happened when I encountered an issue about SO_BINDTODEVICE, and I hope that mtr can get a new release version so Linux distros can update their mtr package.
When people try to build and test their own version of
mtr, if they try to execute./mtrdirectly from the building dir, they may ignore that the wrongmtr-packetbinary is invoked if they have already installed another version ofmtrdon't have environment variableMTR_PACKETset, which potentially leads to wrong result.It would be nice if there's a description on such behavior in README file, or make
mtrtry to loadmtr-packetfrom current directory first.This happened when I encountered an issue about
SO_BINDTODEVICE, and I hope that mtr can get a new release version so Linux distros can update their mtr package.