Don't mis-understand - we appreciate the info. I'm just responding point by
point for completeness. And the list in docs/FAQ is part of the FM...
let's see...
"/usr/ucb/cc which is a stub compiler and good for, IIRC, recompiling the
kernel and absolutely nothing else;"
Yeah - been there, seen that, have the T-Shirt
cc - Sun Commercial Compiler. As I understand things, Sun's moved cc over
the years to be more compatible with the C standards (which gcc is pretty
well fully compatible). But it still has to support the old 'familiar'
Sunisms. So the chances of cc working are better than they used to be.
Still, there are a lot of subtle things behind the scenes that are different
(malloc() library, different .h file arrangements, etc.).
Cost-wise, since ntop is free software, there's no way I can justify paying
for cc. That's true of a lot of users...
For that reason, and for compatibility (for example, I suspect the alloca.h
issue is due to different .h files between the two compilers), gcc is the
supported (and *STRONGLY* recommended) compiler.
Hence the correction - I would not want people to assume we support Sun's cc
(*especially*, say if they're running 2.5 or something older). If it seems
to work, great, if not, well, use gcc.
"FWIW, line 1531 of configure is: for ac_prog in gawk mawk nawk awk" - yeah,
that's automatically generated by automake/autoconf. There are a couple of
things which I know don't work under awk - scripts in utils/ - but the
trivial ./configure stuff does work, so as you say, there's no real reason
to worry too much. I suppose I could add this, after the AC_PROG_AWK in
configure.in:
if test "x${AWK}" = "x"; then
echo
echo
"*******************************************************************"
echo "*"
echo "* WARNING: The test for AWK indicates you do not have any"
echo "* version of Awk installed."
echo "*"
echo "* ntop requires gawk or at least mawk."
echo "*"
echo "*>>> Aborting"
echo "*"
echo "*??? 1. Install gawk"
echo "*"
echo
"*******************************************************************"
echo
exit 0
elif test "x${AWK}" = "xawk" ||
test "x${AWK}" = "xnawk"; then
echo
echo
"*******************************************************************"
echo "*"
echo "* WARNING: The test for AWK indicates you have the original
awk"
echo "* or nawk installed."
echo "*"
echo "* ntop requires gawk or at least mawk."
echo "*"
echo "*>>> Continuing, but some options (e.g. --enable-showoses) "
echo "* may not work."
echo "*"
echo "*??? 1. Install gawk"
echo "*"
echo
"*******************************************************************"
echo
HAS_WARNING="yes"
fi
(Try dropping it into configure.in, recreate configure from configure.in via
autoconf and let me know if it works)
"_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" - I used to, and configure.in ballooned to
over 4500 fragile lines... It's a slippery slope - add special coding for
the odd place one OS puts openSSL, and all of a sudden there are 50 places
to check. No joke -- once upon a time, openSSL used to install into
version#ed directories, which could be placed into six or seven locations on
different OSes...
groff vs. nroff - "Heh. What, you think that I have groff on this system?
:)" Two answers:
1) For stable releases: Unless you changed ntop.8, it shouldn't have to
recreate it. At least For those, I make sure that all the generated files
are recreated in the .tgz and rpms...
2) development (cvs): Yeah, actually I do expect it. If you're playing with
the development (cvs) version, I really DO expect you to have all the tools
installed - Luca can be bad about committing updates for generated things
into the cvs...
@filename - try #define PARAM_DEBUG in globals-defines.h and see what the
debug messages show is happening during startup.
Guess I could add "... and stops" to "display OS Support information"
Options:
--with-rrd-root=/usr/local/rrdtool \
--with-rrd-lib=/usr/local/rrdtool/lib \
--with-rrd-include=/usr/local/rrdtool/include \
if you specify lib and include, it ignores root.
These shouldn't be required...
--with-pcap-lib=$LI \
--with-pcap-include=$IN \
--with-gdbm-lib=$LI \
--with-gdbm-include=$IN \
--with-libpng-lib=$LI \
--with-libpng-include=$LI \
It should successfully find them in /usr/local - that is one of the standard
places to look. Unless, of course, the cc vs. gcc or lack of gnu ld means
those aren't defaults??? Could be...
-xO5... hummmm... the highest stress ntop places on code is probably the
timing sensitive pieces, i.e. how fast it can handle packets so they don't
get queued up. Without a lot of understanding of the specific optimizations
it's applying, I couldn't begin to guess... I suppose, it will either run
or die in strange and horrible ways with/without -xO5
I also seem to recall that the 'bash' installed by Sun is 2.03(?)... might
be mistaken. There are some dependencies in the generated test statements
and such in configure, where IIRC things fail silently under old bash... I
don't remember what the documented dependency is between the auto* tools and
the shells...
Ltr8
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
Of Roy S. Rapoport
Sent: Friday, June 20, 2003 9:30 AM
To: [EMAIL PROTECTED]
Subject: Re: [Ntop-dev] ntop 2.2 on Solaris 9
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
