On Fri, Jun 20, 2003 at 06:05:44AM -0700, Burton Strauss wrote: > We explicitly REQUIRE gcc. I know that under many systems, cc is a > symbolic link to gcc, BUT, when invoked as cc, it often triggers > 'old' behaviors for cc compatibility.
Before I go further, I just want to make sure we're on the same wavelength. My perception of my interaction with the list was as follows: A) I got ntop working on an 'unsupported' platform. I was asked by the configure script to inform this list of such a success; B) I notified the list I succeeded and was asked for more detail; C) I provided more detail last night I'm bringing this up because I feel as though I'm being told to RTFM; IMHO, RTFM is appropriate when someone is asking a question covered by the docs, but I wasn't asking a question or asking for help -- I was notifying you of my success given a non-standard build environment (more on this in in a bit), because you asked me to. I don't think I said (and hell, I could be wrong -- it's been a while since I've slept) "these problems I ran into aren't covered in the docs." BTW, on Solaris, you'll in general get three options: A) A fresh vanilla install of Solaris (any version) will come with /usr/ucb/cc which is a stub compiler and good for, IIRC, recompiling the kernel and absolutely nothing else; B) gcc, if you install it from a package (and maybe, afterward, install it from source -- but you'll obviously have to start from some sort of package); C) cc, the commercial Sun compiler. Obviously, you can occasionally get into namespace conflicts between the (C) cc and the (A) cc, so you need to know what's in your path. It helps that the (A) cc is completely useless :) In my case, I'm actually using the Sun commercial compiler (Sun Forte 8.0), because it's been extensively documented to produce significantly faster binaries. So I appreciate that you require gcc, and you may wish to continue to require gcc based purely on ease of maintainability, but I'm telling you that with very minor tweaking, Sun's commercial compiler worked for me also. > B) > > You only need alloca.h if you have a retarded glibc, one without buildarg, etc. thus > activating the code in util.c. That's a trivial fix. OK. As I mentioned, I wasn't using gcc, so you may either wish to know more about this or ignore it as an unsupported configuration. > F) > > ./configure uses the standard autoconf macro, AC_PROG_AWK, see > http://www.gnu.org/manual/autoconf-2.57/html_node/autoconf_40.html > > We work ok with gawk and mawk, some things don't work with awk and I don't think > we've ever run across nawk. I'm happy to be an outlier :) FWIW, line 1531 of configure is: for ac_prog in gawk mawk nawk awk And then it goes on to test which one is available in your path in order of preference from most to least; so configure, currently, does not do 'The Right Thing' when it can't find gawk/mawk, it just uses what you have and then dies an ugly death. I think it's perfectly reasonable BOFH behavior to say "well, it's not our job to prettily enforce the requirements." > If you read docs/FAQ - the dependency is EXPLICITLY gawk. OK. So take what I said to mean "hey, Solaris 9 didn't have gawk and so I had to install it." _I_ personally, if I was writing a piece of software, would attempt to do dependency checking and exit gracefully rather than die an ugly death, but I figure I'll actually get a say into how ntop does things the day I start paying something for it. > nroff -man ntop.8 works fine under Linux - maybe you have an older version of nroff?? Apparently. > > In the Makefile, we use this to build ntop.txt from ntop.8: > > ntop.txt: ntop.8 > @groff -mandoc -Tascii $< | sed 's/_^H//g' | sed 's/^H[ -~]//g' > ntop.txt Heh. What, you think that I have groff on this system? :) > D) > > man ntop shows > > @filename Yes, I know. Believe it or not, I do occasionally read the docs :) --- 368 nag /usr/local/ntop/bin # ls total 1702 2 ./ 2 ../ 1696 ntop* 2 ntop_args* 369 nag /usr/local/ntop/bin # more ntop_args /usr/local/ntop/bin/ntop \ -P /usr/local/ntop \ -u ntop \ -d \ -a /var/adm/ntop_access \ -L \ -D inorganic.org \ --https-server 3030 \ --throughput-bar-chart \ --local-subnets 192.168.192.0/24 \ 370 nag /usr/local/ntop/bin # ./ntop @ntop_args Wait please: ntop is coming up... FATAL ERROR: unable to open configuration file '@ntop_args' 371 nag /usr/local/ntop/bin # --- I also tried this with the file actually being named '@ntop_args', and the file being in /usr/local/ntop/etc, and the file being in /usr/local/ntop/etc/ntop truss'ing the process shows: --- open("@ntop_args", O_RDONLY) Err#2 ENOENT FATAL ERROR: unable to open configuration file '@ntop_args' --- So for some reason, it looks like ntop tries to open the literal '@ntop_args'. When I tried actually having the file be that name, I got: --- 375 nag /usr/local/ntop/bin # ./ntop @ntop_args Wait please: ntop is coming up... Processing file ntop_args for parameters... FATAL ERROR: Unrecognized/unprocessed ntop options... /usr/local/ntop/bin/ntop run ./ntop --help for usage information Common problems: -B "filter expressions" (quotes are required) --use-syslog=facilty (the = is required) --- > E,G) > > --enable-showoses works perfectly. > > It echos the output of the support levels and stops. That's what it's > designed to do... It is NOT for general use when configuring ntop. That's ... a little strange. I didn't get that from running configure, though I see now that I didn't read very carefully -- "display OS Support information" is not all that ambiguous. > FWIW you also have other ./configure options which aren't valid (or more precisely > are a mix of the 2.2 and development branches). option. Singular. At least, the only option I'm using that's not mentioned when you do 'configure --help' is --enable-ntcsh. Am I missing anything? > As I've said, unless somebody is willing to sponsor it, I've got no way to test > under Solaris 9. OK. I've got a buck in my pocket, so I'm not a real good sponsor opportunity for you. On the other hand, if you decide you want access to a Solaris 9 box, let me know. > The -I's? -I/usr/local/ssl/include should be set automatically based on the > --with-ossl-include value. Yeah; as I mentioned, it seems that specifying the per-package include/lib files didn't seem to do a whole bunch. > Requiring -I/usr/local/include may be an S9 issue, and should be in the case > specific statement with LDFLAGS, although if you install stuff from Sun Freeware, it > goes in other places... Right. While Solaris lets you modify where it looks for libraries, I have not yet managed to figure out how to modify where it looks for header files on a permanent basis. Unfortunately, /usr/local/include is non-standard for Solaris (meaning "Sun says it's not standard," not "I'm the only one who does it this way"). > CFLAGS "-xO5"? O5 is an awfully agressive setting for optimization, > IIRC -X is Solaris specific, so that's probably best done - for those > who want to risk it - via setenv. Heck yeah. '-xO5' shouldn't even work for gcc. It's Forte-specific. Unfortunately, Forte chokes on '-On'. Either way, I know it's very high optimization, but it seems to work for me. Is there any stress testing we can do to see if there are any problems with it? -roy _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
