On Fri, Jun 20, 2003 at 11:01:38AM -0500, Burton M. Strauss III wrote:
> 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...
Absolutely right. On the other hand, there's that free 60 day license
you can get for it, if you care (I'd probably argue that people who run
commercial Solaris clusters should use Sun's cc when possible and should
argue for purchasing a license, but that's not relevant here).
In either case, ignore what I said about it working earlier -- about a
day after ntop started running, it stopped responding to web requests
(connection refused, in fact), so I recompiled with gcc. So far
everything seems good.
> echo
> "*******************************************************************"
[...]
> echo
> "*******************************************************************"
>
> (Try dropping it into configure.in, recreate configure from configure.in via
> autoconf and let me know if it works)
This works and complains appropriately (I'm assuming that the fact echo
and the next line are separated is due to line folding on my MUA's
part).
> 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...
I think that it's perfectly reasonable to check if you can find what
you're looking for and complain otherwise; I don't think "well, let's
also look over there" is all that necessary. Then again, I also think
it's prefectly reasonable to simply say "give it as an option to
configure."
> 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...
Well, I could be wrong, but the latest version of ntop I played with
looks like it's the stable version (ntop-2.2.tgz, 2551153 bytes); it
includes ntop.8 in only source form.
> @filename - try #define PARAM_DEBUG in globals-defines.h and see what the
> debug messages show is happening during startup.
Here it is:
---
Wait please: ntop is coming up...
PARAM_DEBUG: Requested parameter file, 'ntop_args'
PARAM_DEBUG: File size 195
Processing file ntop_args for parameters...
PARAM_DEBUG: fgets() '/usr/local/ntop/bin/ntop \
'
PARAM_DEBUG: -> '/usr/local/ntop/bin/ntop \ '
PARAM_DEBUG: fgets() '-P /usr/local/ntop \
'
PARAM_DEBUG: -> '-P /usr/local/ntop \ '
PARAM_DEBUG: fgets() '-u ntop \
'
PARAM_DEBUG: -> '-u ntop \ '
PARAM_DEBUG: fgets() '-d \
'
PARAM_DEBUG: -> '-d \ '
PARAM_DEBUG: fgets() '-a /var/adm/ntop_access \
'
PARAM_DEBUG: -> '-a /var/adm/ntop_access \ '
PARAM_DEBUG: fgets() '-L \
'
PARAM_DEBUG: -> '-L \ '
PARAM_DEBUG: fgets() '-D inorganic.org \
'
PARAM_DEBUG: -> '-D inorganic.org \ '
PARAM_DEBUG: fgets() '--https-server 3030 \
'
PARAM_DEBUG: -> '--https-server 3030 \ '
PARAM_DEBUG: fgets() '--throughput-bar-chart \
'
PARAM_DEBUG: -> '--throughput-bar-chart \ '
PARAM_DEBUG: fgets() '--local-subnets 192.168.192.0/24 \
'
PARAM_DEBUG: -> '--local-subnets 192.168.192.0/24 \ '
PARAM_DEBUG: effective cmd line: './ntop /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 \
'
PARAM_DEBUG: 0. './ntop'
PARAM_DEBUG: 1. '/usr/local/ntop/bin/ntop'
PARAM_DEBUG: 2. ' '
PARAM_DEBUG: 3. '-P'
PARAM_DEBUG: 4. '/usr/local/ntop'
PARAM_DEBUG: 5. ' '
PARAM_DEBUG: 6. '-u'
PARAM_DEBUG: 7. 'ntop'
PARAM_DEBUG: 8. ' '
PARAM_DEBUG: 9. '-d'
PARAM_DEBUG: 10. ' '
PARAM_DEBUG: 11. '-a'
PARAM_DEBUG: 12. '/var/adm/ntop_access'
PARAM_DEBUG: 13. ' '
PARAM_DEBUG: 14. '-L'
PARAM_DEBUG: 15. ' '
PARAM_DEBUG: 16. '-D'
PARAM_DEBUG: 17. 'inorganic.org'
PARAM_DEBUG: 18. ' '
PARAM_DEBUG: 19. '--https-server'
PARAM_DEBUG: 20. '3030'
PARAM_DEBUG: 21. ' '
PARAM_DEBUG: 22. '--throughput-bar-chart'
PARAM_DEBUG: 23. ' '
PARAM_DEBUG: 24. '--local-subnets'
PARAM_DEBUG: 25. '192.168.192.0/24'
PARAM_DEBUG: 26. ' '
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)
---
I don't see anything quite obvious in this expanded debug; any
suggestions?
> Guess I could add "... and stops" to "display OS Support information"
Might be helpful for other hard-of-reading people.
> 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...
I found that it couldn't successfully find them, typically.
-roy
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
