[Ulf Lamping <ulf.lamping@xxxxxx>]

Hi Joe!

First of all, thanks for taking the time to write this down.

As I don't have a clue what's missing in the User's Guide on this topic, 
I noticed that there was a recent change in the configure script 
addressed to this problem which may make a change in the user's guide 
obsolete.

Could one of the *NIX gurus have a look and point me the way what to do now?

Regards, ULFL
>   
>   
> OK - I am working here from the supposedly current version of 
> user-guide-us.pdf - at least it is the version that I downloaded about 
> 2.5 minutes ago from http://wireshark.org/docs/ .
> I am on pdf page 32, doc page 18, section 2.4 (Building Wireshark from 
> source under UNIX), numbered bullet 3. I am quoting herein the entire 
> text of bullets 2, 3, and 4 for context - to wit:
> "
> 2. Change directory to the Wireshark source directory.
> 3. Configure your source so it will build correctly for your version of 
> UNIX. You can do this with the
> following command:
> ./configure
> If this step fails, you will have to rectify the problems and rerun 
> configure. Troubleshooting hints
> are provided in Section 2.6, “Troubleshooting during the install on Unix”.
> 4. Build the sources into a binary, with the make command. For example:
> make
> "
>
> For those that have been following along, I encountered an error at 
> bulleted item 3, where the ./configure failed due to an improper build 
> option for UCD-SNMP. The fix was to do the configure step by the 
> following invocation:
> ./configure --with-ssl .
>
> I personally do not (yet) have the breadth of experience to know whether 
> or not the default should be to invoke ./configure with the --with-ssl 
> option. If so, then here in item 3 is where the fix to the install 
> procedure should be made. Again assuming this is proper, the text here 
> would change to be:
> '
> 3. Configure your source so it will build correctly for your version of 
> UNIX. You can do this with the
> following command:
> ./configure --with-ssl
> If this step fails, you will have to rectify the problems and rerun 
> configure. Troubleshooting hints
> are provided in Section 2.6, “Troubleshooting during the install on Unix”.
> '
>
> I rather suspect however, that there may be something about my system 
> that makes it non-typical (comments?) in its need for a non-default 
> build of UCD-SNMP. Changing our assumption to this being the case, the 
> above suggested change is probably not appropriate. There is another 
> section of the doc that deals with exceptions encountered during the 
> build. We are now directed by bulleted item 3 to section 2.6, 
> “Troubleshooting during the install on Unix”. We find this section on 
> pdf page 35, doc page 21, quoted below in its entirety - to wit:
> "
> 2.6. Troubleshooting during the install on Unix
> A number of errors can occur during the installation process. Some hints 
> on solving these are provided
> here.
> If the configure stage fails, you will need to find out why. You can 
> check the file config.log in the
> source directory to find out what failed. The last few lines of this 
> file should help in determining the
> problem.
> The standard problems are that you do not have GTK+ on your system, or 
> you do not have a recent
> enough version of GTK+. The configure will also fail if you do not have 
> libpcap (at least the required
> include files) on your system.
> Another common problem is for the final compile and link stage to 
> terminate with a complaint of: Output
> too long. This is likely to be caused by an antiquated sed (such as the 
> one shipped with Solaris).
> Since sed is used by the libtool script to construct the final link 
> command, this leads to mysterious problems.
> This can be resolved by downloading a recent version of sed from 
> http://directory.fsf.org/GNU/
> sed.html.
> If you cannot determine what the problems are, send mail to the 
> wireshark-dev mailing list explaining
> your problem, and including the output from config.log and anything else 
> you think is relevant, like
> a trace of the make stage.
> "
>
> I would suggest that if, as Jeff Morriss suggests, this issue is 
> encountered on a more-than-infrequent basis, the text of this section 
> may be changed to read:
> '
> 2.6. Troubleshooting during the install on Unix
> A number of errors can occur during the installation process. Some hints 
> on solving these are provided
> here.
> If the configure stage fails, you will need to find out why. You can 
> check the file config.log in the
> source directory to find out what failed. The last few lines of this 
> file should help in determining the
> problem.
> The standard problems are that you do not have GTK+ on your system, or 
> you do not have a recent
> enough version of GTK+. The configure will also fail if you do not have 
> libpcap (at least the required
> include files) on your system.
> The configure stage may sometimes fail due to an incompatible 
> configuration of ucd-snmp. If the last few lines of the configure stage 
> fail with a console indication of an error involving 'UCD SNMP', the 
> error may be skirted by passing an option to the configuration process. 
> This can often be addressed by configuring with the invocation
> ./configure --with-ssl.
> Another common problem is for the final compile and link stage to 
> terminate with a complaint of: Output
> too long. This is likely to be caused by an antiquated sed (such as the 
> one shipped with Solaris).
> Since sed is used by the libtool script to construct the final link 
> command, this leads to mysterious problems.
> This can be resolved by downloading a recent version of sed from 
> http://directory.fsf.org/GNU/
> sed.html.
> If you cannot determine what the problems are, send mail to the 
> wireshark-dev mailing list explaining
> your problem, and including the output from config.log and anything else 
> you think is relevant, like
> a trace of the make stage.
> '
>
>
> The astute observer will not that I have inserted the fourth paragraph. 
> It reflects an ignorant noob's view of what may or may not be going on 
> under the hood. I imagine there is likely a better way to address this 
> issue, which I shall learn all about in time. All I know, is that had 
> this paragraph been in the user-guide-us.pdf, I would not yet have met 
> all you fine contributors on wireshark-dev.
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>