mac os x 安装 wireshark 的问题

ameimeng

　　原文链接：http://ask.wireshark.org/questions/10289/why-doesnt-the-wireshark-team-fix-the-macosx-version-of-wireshark-install
　　


Why doesn't the Wireshark Team fix the MacOsx version of wireshark install
　　
　　
I ran the Wireshark installation and it fails to start. When run from the command line I get the following error: Incompatible library version: wireshark-bin requires version 14.0.0 or later, but libfreetype.6.dylib provides version 13.0.0
　　
I googled around and saw suggestions such as update freetype and macports. I did this and am currently running latest macports and $ sudo port installed | grep freetype shows freetype @2.4.9_1
(active) It doesn't get anymore current than this. Another link on the web suggested that your installation package is broken.
　　
When if ever do you plan to fix this?

The more I dig in to this the more things seem to be related to Wireshark dependencies on the very latest and greatest X11 and GTK code. This is problematic. First of all X11 is no longer supported by the
Mac. Getting newer versions of GTK to build on the Mac (1.6.8) have been unsuccessful due to one or other dependencies. Why is it that the team has to use the latest graphics code which is not widely distributed on the Mac? Are you doing heavy duty 3D animations
with advanced frame rates or something? You shouldn't need a gaming subsystem to run the UI.　　


　　Answer:
　　
　　
Wireshark is not built with anything from MacPorts, so a MacPorts update will probably not update anything that Wireshark uses.
　　
My MacBook Pro is running 10.6.8 with all security updates, and has libfreetype with a compatibility version of 14.0.0:

$ otool -L /usr/X11/lib/libfreetype.6.dylib
/usr/X11/lib/libfreetype.6.dylib:
/usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, current version 14.2.0)

　　
The problem is that:

• We build the version of GTK+ distributed with Wireshark against the libraries installed on the buildbot, rather than the ones in the Snow Leopard SDK, which means that if you don't have as up-to-date a
  version of the OS as the one on the buildbot, there is a risk that the resulting binary won't work on your machine.
  
• libfreetype uses GNU libtool, and the way libtool does versioning can cause library major version numbers to change with new versions even if the new version of the library is backwards-compatible
  with the old one.
  
• Apple sometimes updates libfreetype.
  

　　
The first of those is bug 5937 in the Wireshark bug database. It requires some work on the Wireshark macosx-setup.shscript
used to build the support libraries, as well as on the configure scripts etc., to allow Wireshark and its support libraries to be built against the SDK; it also then requires that the buildbots rebuild the support libraries against the SDK.
　　
The second of those is a bug in the Apple bug database, but it's a bit tricky, and arguably the right thing to do in the shorter term is to fix the first of those, which would obviate the need for a change to the library versioning scheme.
　　
The third of those, well, sometimes there are bugs in libfreetype, and some of them might even cause security issues, so Apple should update it.
　　
The requirement for newer versions of X11 libraries has nothing to do with a requirement for high-end 3D graphic performance - it's just a consequence of the way the builds are currently being done and of the way library version numbers are assigned. Apple's
not likely to spend a lot of time and energy worrying about frame rates for X11 clientsoftware, and, in any case, libfreetype isn't a fancy 3D graphics library, it's
just a font rendering engine, so it's not as if the latest version is going to make much difference to frame rates in X11 applications.
　　
And, yes, in the longer term we should stop using GTK+-on-X11 on the Mac, and probably stop using "native" GTK+ on Windows. There is a "native" GTK+ for OS X, which would avoid the requirement for the X11 server, and possibly avoid using the version
of libfreetype that comes with Apple's X11, but I think that has some issues of its own. Currently, there's work in progress to support using Qt for the GUI; Qt's
OS X and Windows support is, I think, better than GTK+'s, and its X11 support is probably at least as good as GTK+'s (and would probably make people using Wireshark on KDE happier :-)).