Make sshdump addition to the package conditional depending on whether
it is actually built.
Change-Id: Ifeaa134fdb3dcd88e48ff0c796f0c21c804eba77
Reviewed-on: https://code.wireshark.org/review/12023
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
It can happen that the $binary_list contains apps that are not compiled
(eg. for the lack of a lib). In this case the binary can't be added to
the package. Fixed checking that the binary going to be signed is present.
Change-Id: Iefd9438de972302523ba28596e905b11513a4fea
Reviewed-on: https://code.wireshark.org/review/11968
Reviewed-by: Gerald Combs <gerald@wireshark.org>
sshdump is an extcap module that allows dumping from a remote host using an ssh connection.
It goes with the existing extcap plugin interface.
Change-Id: I8987614fdd817b8173a50130812bc643a4833bca
Reviewed-on: https://code.wireshark.org/review/11402
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
When creating a bundle using osx-app.sh (i.e. when we're using
Autotools), make sure we copy androiddump to the extcap subdirectory.
Change-Id: Iabb24ae969ae77856f15dd94120cc6e395311198
Reviewed-on: https://code.wireshark.org/review/11215
Reviewed-by: Gerald Combs <gerald@wireshark.org>
For libraries, instead of prefixing dependent library paths with
@executable_path/../Framework, prefix them with @rpath. This should let
us load them from different directory depths.
Remove any LC_RPATH not in an allowed list of prefixes. This should keep
us from leaking paths specific to the build environment and user, and
should make any portability problems more obvious.
Add either @executable_path/../Frameworks or
@executable_path/../../Frameworks as an LC_RPATH depending on which
actually exists. This lets us place androiddump in the extcap
subdirectory.
Add error checking in a few places and make sure we detect failures in
subshells.
Add a macdeployqt buglink.
Bug: 11620
Change-Id: I43ef02ecc6f741761fcb9827c0b0b7b2ef16fa9a
Reviewed-on: https://code.wireshark.org/review/11205
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Add a dmg_package_prep target as an alias to app_bundle. Rename the
osx-dmg target to dmg_package. This matches the Windows packaging
target names.
In osx-app.sh, make sure we rpathify the bundle plugin directory.
Change-Id: If41195c9d405ad6bff865625500a8227b77e8092
Reviewed-on: https://code.wireshark.org/review/10734
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Adding the additional rpath in the build process appears to have fixed
the problem I was trying to debug.
Change-Id: I518deea67837f7e084e503b8e5ae7c3f188df3c8
Reviewed-on: https://code.wireshark.org/review/9628
Reviewed-by: Guy Harris <guy@alum.mit.edu>
macdeployqt will stuff them into the bundle for us; exclude anything in
the Qt frameworks directory from the lists of dependencies for us to
copy or munge. (We don't copy them correctly - that results in the
underlying binary being copied to the Frameworks directory - and we
leave it up to macdeployqt to do the munging.)
Change-Id: I10cfb8dcb2abadde9d5c52252979267912710f80
Reviewed-on: https://code.wireshark.org/review/9627
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Qt 5.5 and later have @rpath-based install names for the frameworks,
which means that, if they're not installed in some frameworks directory
searched by default (such as /Library/Frameworks) - which is the default
case with the Qt installer - they won't be found by default.
Add the directory in which the frameworks exist as an rpath in the
Wireshark binary, so that they'll be found, and then remove it from the
Wireshark binary in the app bundle, as the directory in which the
frameworks exist on the machine on which Wireshark was built is
irrelevant to the machines on which it's being deployed - the frameworks
are included in the bundle, and we already add an rpath to find them
there.
Change-Id: I54e033743e7b17eab26976064dcd7cd000f97c78
Reviewed-on: https://code.wireshark.org/review/9625
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I have some other hammers to try it hit it with to get it to actually
work with Qt 5.5.
Change-Id: Ie20ccbcee62fa48f768ba22478d07b9dc18d0139
Reviewed-on: https://code.wireshark.org/review/9623
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We need to preserve the full path of the framework binary.
Change-Id: I3a13eaffc07028a26fbd970db02cc1cce3fdcd5d
Reviewed-on: https://code.wireshark.org/review/9621
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That's easier than trying to carefully copy the relevant bits.
Change-Id: I2f174a735bf91f6434929c25ca33aced03e19597
Reviewed-on: https://code.wireshark.org/review/9620
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Copy only the stuff needed at run time; don't bother with all the
headers, etc..
Change-Id: Id9d2ec916b6742a6cb6e2ec3c0f7ed1a65a8a93c
Reviewed-on: https://code.wireshark.org/review/9617
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Do it in a loop, so we can change it to handle Qt 6 if, as, and when it
comes out (assuming they label its packages as Qt6Package).
Change-Id: I1d33d3e9726981b1940fb4409184c486628cb31b
Reviewed-on: https://code.wireshark.org/review/9615
Reviewed-by: Guy Harris <guy@alum.mit.edu>
When looking for Qt framework dependencies, look for dependencies that
begin either with @rpath or with the Qt framework directory.
Then, first transform @rpath/ to a path relative to the Qt framework
directory, and then strip off everything past the framework directory,
to get the absolute path of the framework directory (not of the
framework binary - we want to copy the whole framework).
In the loop looking for dependencies on things *other* than Qt
frameworks, exclude Qt framework references with absolute paths from the
dependencies we find; they get processed later. (We already excluded
those with @rpath paths.)
Change-Id: I1e345a5fb82c758d5c1541693b46cb36d2677fab
Reviewed-on: https://code.wireshark.org/review/9614
Reviewed-by: Guy Harris <guy@alum.mit.edu>
macdeployqt doesn't actually seem to deploy any of Qt into the app
bundle, probably because we're using it in a fashion they didn't intend
(i.e., not doing everything with *their* build tools), so we just extend
our dependency-binding stuff to handle the Qt libraries, and copy over
the Qt plugins ourselves.
We also add the rpaths to the executables and libraries as part of the
app bundle building process; I thought it'd fix macdeployqt's problem,
but it didn't, however, it's probably cleaner to do it there anyway.
Change-Id: I134c2b1a32e168e82de67f0b674d17167481d69a
Reviewed-on: https://code.wireshark.org/review/9612
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Determine what type of X11 (bundled from Apple, unbundled XQuartz) we
should have and what type we do have.
If we don't have any installed, don't tell X11 to do anything, as that
just pops up a "where is X11?" dialog; that's information the user
shouldn't need to tell the system if it is installed, and it's
information for which the user shouldn't be asked if it's not installed
- and if they're asked, they might answer incorrectly, leaving a system
that doesn't properly launch X11 for Wireshark. (See various
ask.wireshark.org questions about this, for example.)
Pick up some changes from newer versions of Inkscape, such as using
unsigned char *, not using FSSpecs, and adding some comments, while
we're at it.
Change-Id: Ic9a2b25938c4eec5628d1c16c7db28aa0714203e
Reviewed-on: https://code.wireshark.org/review/8559
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Reviewed-on: https://code.wireshark.org/review/8561
Make sure the target location for extcap executables and extcap_dir
match on OS X.
Set the extcap directory to Contents/MacOS/extcap. The Mac Developer
Library documentation doesn't explicitly define "Resources", but
examples include data files and not executables. It does state that
executables shouldn't go into PlugIns.
Make sure we rpathify androiddump.
Change-Id: If36c762e2a1991c26e5c01a870deaf191bcf9f94
Reviewed-on: https://code.wireshark.org/review/8093
Reviewed-by: Gerald Combs <gerald@wireshark.org>
The androiddump binary ends up in the top-level source directory, not
the extcap subdirectory.
Change-Id: Ia306b35211b885b817802a6a22ed9dbbe07f2532
Reviewed-on: https://code.wireshark.org/review/8037
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add missing androiddump stuff like:
- release notes
- documentation
- Windows nmake support
- running androiddump as a windows application instead of console on Windows
- addition of androiddump to the Windows installer
Change-Id: I3bc6cc70e4dc96c0cd776f3d965dd2aa0309995d
Reviewed-on: https://code.wireshark.org/review/7981
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
the make that comes with *BSD and other systems now.
Change-Id: Ib2eee8d37e7029202675bac35839b1c0d5fc5131
Reviewed-on: https://code.wireshark.org/review/6320
Reviewed-by: Stephen Fisher <sfisher@sdf.org>
Look for the binary in various places, rather than looking for
particular directories and adding them to the path. That lets us use
the PackageMaker binary from the PackageMaker.app bundle (it can either
be run as a GUI app or from the command line), so you don't have to have
a symlink to it from one of the directories in question.
Change-Id: I1ad701291698544f96d419663f0b4a669876d2f1
Reviewed-on: https://code.wireshark.org/review/5077
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add a -cb/--create-bundle option to osx-app.sh which builds the
application bundle. Use it in Autotools. (CMake does this by default.)
Copy over linker flags from configure.ac to CMakeLists.txt to support
rpathification and code signing.
Add an osx-app custom target to CMake.
Change-Id: I6c20a1c27f8954aaea62904b7425b9312d994803
Reviewed-on: https://code.wireshark.org/review/4918
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Also, update a comment to more accurately describe what a loop is doing,
and get rid of an unused variable.
Change-Id: I948fc4ad758152b483450bf74f653087c892ad3a
Reviewed-on: https://code.wireshark.org/review/2360
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts to the way we did it prior to the switch to Qt; with GTK+,
Contents/MacOS/Wireshark is just a launcher, and the Wireshark binary is
in Contents/Resources/bin/wireshark-bin, and the appropriate rpath entry
would be @executable_path/../lib - @executable_path/../Frameworks, which
works for the Qt version, in which Contents/MacOS/Wireshark is the
actual executable, doesn't work for the GTK+ version.
This should fix bug 10185.
Change-Id: I4e50a4ead8f29a742c97a9001c821aabe1fa5e65
Reviewed-on: https://code.wireshark.org/review/2347
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, if we crash in the middle, there's still something installed
that will try to set the permissions on the BPF devices.
Change-Id: Ie0c32f9eaca08bdbb359d07e47f20c664bc66411
Reviewed-on: https://code.wireshark.org/review/2023
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Graham Bloice