--- embedaddon/mtr/README 2016/11/01 09:33:48 1.1.1.2 +++ embedaddon/mtr/README 2019/10/21 14:25:31 1.1.1.3 @@ -6,7 +6,7 @@ WHAT IS MTR? As mtr starts, it investigates the network connection between the host mtr runs on and a user-specified destination host. After it determines the address of each network hop between the machines, - it sends a sequence ICMP ECHO requests to each one to determine the + it sends a sequence of ICMP ECHO requests to each one to determine the quality of the link to each machine. As it does this, it prints running statistics about each machine. @@ -31,14 +31,17 @@ INSTALLING make install - Note that mtr must be suid-root because it requires access to raw IP - sockets. See SECURITY for security information. + Note that mtr-packet must be suid-root because it requires access to + raw IP sockets. See SECURITY for security information. - Older versions used to require a non-existant path to GTK for a + Older versions used to require a non-existent path to GTK for a correct build of a non-gtk version while GTK was installed. This is - no longer neccesary. ./configure --WITHOUT_GTK should now work. + no longer necessary. ./configure --without-gtk should now work. If it doesn't, try "make WITHOUT_X11=YES" as the make step. + On Solaris, you'll need to use GNU make to build. + (Use 'gmake' rather than 'make'.) + On Solaris (and possibly other systems) the "gtk" library may be installed in a directory where the dynamic linker refuses to look when a binary is setuid. Roman Shterenzon reports that adding @@ -47,27 +50,33 @@ INSTALLING you're out of luck when you use the sun LD. That's not quite true, as you can move the gtk libraries to /usr/lib instead of leaving them in /usr/local/lib. (when the ld tells you that /usr/local/lib is untrusted - and /usr/lib is trusted, and you trust hte gtk libs enough to want them + and /usr/lib is trusted, and you trust the gtk libs enough to want them in a setuid program, then there is something to say for moving them to the "trusted" directory.) - On Solaris, linking usually fails to find "wattr" or something like that. - Somehow, I can't seem to be able to automate "configure" finding the right - libs on Solaris. So, the solution is that you cut-and-paste the line - doing the linking into a terminal window, and add "-lcurses" by hand. - Then it will link. Help on how to catch this in autoconf appreciated. + Building on MacOS should not require any special steps. - On Mac OS X the nameserver8_compat.h needs to be included. I put the - include inside an "#if 0" section in the file "dns.c". If someone - knows how to make this automatic using autoconf / the configure script, - please tell me.... +BUILDING FOR WINDOWS - This should now also work: - ./configure CFLAGS="-arch i386 -arch x86_64" LIBS="-lresolv" \ - --without-gtk --disable-endian-check --disable-dependency-tracking + Building for Windows requires Cygwin. To obtain Cygwin, see + https://cygwin.com/install.html. When installing Cygwin, select + the 'lynx' package for installation. lynx is required by apt-cyg. + Next, install apt-cyg for easy installation of the remaining + components. See https://github.com/transcode-open/apt-cyg. + Install the packages required for building: + apt-cyg install automake pkg-config make gcc-core libncurses-devel + + Build as under Unix: + + ./bootstrap.sh && ./configure && make + + Finally, install the built binaries: + + make install + WHERE CAN I GET THE LATEST VERSION OR MORE INFORMATION? mtr is now hosted on github. @@ -76,18 +85,17 @@ WHERE CAN I GET THE LATEST VERSION OR MORE INFORMATION See the mtr web page at http://www.BitWizard.nl/mtr/ - There used to be a mailinglist, but all it got was spam. So - when the server was upgraded, the mailing list died. + Bug reports and feature requests should be submitted to the Github + bug tracking system. - Bug reports and feature requests should be submitted to the - bug tracker at launchpad: https://launchpad.net/mtr/+bugs + Patches can be submitted by cloning the Github repository and issuing + a pull request, or by email to me. Please use unified diffs. Usually + the diff is sort of messy, so please check that the diff is clean and + doesn't contain too much of your local stuff (for example, I don't + want/need the "configure" script that /your/ automake made for you). - Patches can be submitted by Email to me, or submitted to the - bug tracker. Or you can clone the github repository and issue a pull - request. Please use unified diffs. Usually the diff is sort of - messy, so please check that the diff is clean and doesn't contain too - much of your local stuff (for example, I don't want/need the "configure" - script that /your/ automake made for you). + (There used to be a mailinglist, but all it got was spam. So + when the server was upgraded, the mailing list died.) -- REW