Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Install failure at configure stage

From: Joe Breher <linux@xxxxxxxxxxx>
Date: Wed, 27 Sep 2006 19:19:01 -0600
Ulf Lamping wrote:
Joe Breher wrote:
Jeff Morriss wrote:
Sorry, my post was a question to the developers to help make it easier for people in general.

Anyway, for your case, just reconfigure Wireshark like this:

./configure --with-ssl

This worked. Thanx.
A note in the user-guide-us.pdf might have staved off my inquiry.
You might provide a detailed text and at which place to put this into the guide.
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.