Wireshark-bugs: [Wireshark-bugs] [Bug 10185] OS X: 1.12.0rc2 developer release will not start
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Tue, 17 Jun 2014 21:22:22 +0000

changed bug 10185

What Removed Added
Priority Low High
Status UNCONFIRMED CONFIRMED
Version Git 1.12.0
Summary OSX: Developer release will not start OS X: 1.12.0rc2 developer release will not start
Ever confirmed   1
Severity Major Blocker

Comment # 1 on bug 10185 from 
Happens for me, too.  libfiletap *is* in the Contents/Frameworks subdirectory
of the app bundle, along with the other Wireshark shared libraries.

otool -l on Contents/Resources/bin/wireshark-bin reports:

Load command 52
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/../lib (offset 12)
Load command 53
          cmd LC_RPATH
      cmdsize 48
         path @executable_path/../Frameworks (offset 12)

The dyld man page says

       @executable_path/
              This variable is replaced with the path to  the  directory  con-
              taining the main executable for the process.  This is useful for
              loading dylibs/frameworks embedded in a .app directory.  If  the
              main  executable  file is at /some/path/My.app/Contents/MacOS/My
              and  a  framework  dylib  file  is   at   /some/path/My.app/Con-
              tents/Frameworks/Foo.framework/Versions/A/Foo,  then  the frame-
              work load path could be  encoded  as  @executable_path/../Frame-
              works/Foo.framework/Versions/A/Foo  and the .app directory could
              be moved around in the file system and dyld will still  be  able
              to load the embedded framework.

so @executable path would be /Applications/Wireshark.app/Contents/Resources/bin
and @executable_path/../Frameworks would be
/Applications/Wireshark.app/Contents/Resources/bin/../Frameworks, i.e.
/Applications/Wireshark.app/Contents/Resources/Frameworks, which doesn't exist.

Either:

    1) the rpath entry @executable_path/../lib should be removed, as there's no
lib directory, and the rpath entry @executable_path/../Frameworks needs to be
changed to @executable_path/../../Frameworks

or

    2) the rpath entry @executable_path/../Frameworks should be removed, and
the libraries should be put in Contents/Resources/lib rather than
Contents/Frameworks.

I suspect this is a side-effect of going with Qt and then going back to GTK+
for 1.12.0, so I suspect the right thing to do for 1.12.0 is 2), which I think
undoes some of the "going with Qt" changes for the OS X packaging.

You are receiving this mail because:
  • You are watching all bug changes.