You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 wrongmtr-packet
binary is invoked if they have already installed another version ofmtr
don't have environment variableMTR_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 loadmtr-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.The text was updated successfully, but these errors were encountered: