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>
Only one is necessary; get rid of the startup item.
Change-Id: I0bd2dabb3fc286ccd0e6634bc112e20602624c86
Reviewed-on: https://code.wireshark.org/review/2016
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We're not using the Utilities directory; don't create it and don't fill
it in.
Change-Id: I7ba66b415a2e5a6aff77d4bdb57b2ca176bcd789
Reviewed-on: https://code.wireshark.org/review/2009
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(Using sed : sed -i '/^\# \$Id\$/,+1 d') (start with dash)
Change-Id: Ia4b5a6c2302f6a531f6a86c1ec3a2f8205c8c2dd
Reviewed-on: https://code.wireshark.org/review/881
Reviewed-by: Anders Broman <a.broman58@gmail.com>
(Using sed : sed -i '/^ \$Id\$/,+1 d') (No star only 2 spaces before)
Change-Id: Id7b254031769a9dca2941304e4d3a0f4bdbc3f54
Reviewed-on: https://code.wireshark.org/review/883
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Issue found by rols
The installer puts the normal included plugins (e.g. mate, wimax) in
/Applications/Wireshark.app/Contents/Frameworks/wireshark/plugins,
however the global plugins directory is set to
/Applications/Wireshark.app/Contents/Resources/lib/wireshark/plugins
(as it was in previous versions) so no plugins load at startup.
In order to make them load you have to create this directory and
copy the plugins there, or put them in your personal directory.
From remark of Gerald, use recommandation of Bundle Programming Guide (use Contents/PlugIns for plugin)
https://developer.apple.com/library/mac/documentation/corefoundation/conceptual/cfbundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19
Change-Id: Ib1ae7da48a8fa94f7037912cd44c05532a238b71
Closed-bug: 9854
Reviewed-on: https://code.wireshark.org/review/602
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Replace g_memmove with memmove
However there still one move g_memmove related code in "packaging/macosx/native-gtk/glibconfig.h".
svn path=/trunk/; revision=54472
Add a cli-preinstall script that creates missing parts of the
installation path and sets their permissions. Simply copy
"utility-launcher" to "wireshark" instead of renaming it at install
time. Explicitly set its ownership and permissions. Pretty-print some of
the PackageMaker XML files via `xmllint --format --recover`.
svn path=/trunk/; revision=53281
Specify "Application" or "Installer" code signing identities as needed.
Switch back to productbuild for the package. That seems to be the
correct utility to use. Give the package an ID. Package signing is still
broken but this appears to be closer to being correct.
svn path=/trunk/; revision=53211
Sign executables, libraries, frameworks, plugins, and bundles as per the
Code Signing Guide. Check our work with spctl. Use "bundle" to
differentiate what we're doing with the package script.
svn path=/trunk/; revision=52746
If we don't find Wireshark.app in WIRESHARK_APP_DIR or
/Applications/Wireshark.app, look for it using its bundle ID. Add a
description of this process to the Read Me First files. Look for
executables in the right subdirectory depending on our UI flavor.
Make sure we don't add GTK+-specific items to the app bundle if we're
using Qt.
svn path=/trunk/; revision=52502
Instead of trying to match libraries from $LIBPREFIX, exclude libraries
that aren't in well-known system paths and which haven't previously been
@rpathified.
svn path=/trunk/; revision=52479
The welcome screen in the Qt port runs "dumpcap -S" to draw sparklines.
On OS X this means that it holds open a BPF device for each interface.
Trying to capture using another instance of Wireshark (or tcpdump, or
tshark, or...) will trigger the creation of an additional BPF device but
we won't have permission to use it. Forcing device creation at startup
works around this.
svn path=/trunk/; revision=52227
we're running from inside an OS X app bundle and, if we are, save the
pathname of the top-level bundle directory and use it to get the
pathnames of global data files, plugins, and Python modules.
This obviates the need to set special environment variables for them in
the launcher scripts, so get rid of the commands to do that.
The @rpathification of binaries also obviates the need for the
commented-out setting of DYLD_LIBRARY_PATH, so get rid of that as well.
svn path=/trunk/; revision=51306
deployment target; if --disable-osx-deploy-target was specified, set it
to the OS version on which we're building - minor/dot-dot version and
all - as there's no guarantee that it'll work on *any* version earlier
than that.
svn path=/trunk/; revision=51060
@executable_path/../lib as well as /usr/local/lib, so we can use @rpath
in the install names in the executables and libraries in the application
bundle.
Have the osx-app.sh script tweak all references to libraries from
/usr/local/lib in all executables, libraries, and plugins in the app
bundle to use @rpath. (The "all" is important; it fixes the GTK+ crash
mentioned in the comment in osx-app.sh. The notion of doing all of them
came from the osx-app.sh script in a newer version of Inkscape.)
This renders the setting of DYLD_LIBRARY_PATH in the wrapper scripts in
the bundle unnecessary; remove it. (Ideally, we should try to get rid
of the wrapper scripts entirely, but that might have to wait for us to
switch to using Qt.)
svn path=/trunk/; revision=50560
Don't rpathify system libraries.
Rpathify with @rpath, not @executable_path.
Use the right path for the binaries and libraries.
svn path=/trunk/; revision=50547
when building for OS X; that causes the MACOSX_DEPLOYMENT_TARGET
environment variable to be set when building (so that, for example, we
don't use linker features available on the version on which we're
building but not on the minimum OS version for which we're building),
and causes the SDK for that version to be used (so that, for example, we
don't link with libraries with later version numbers than the ones
provided with the OS version for which we're building).
svn path=/trunk/; revision=50410
/Applications/Xcode.app/Developer first (for Xcode 4 and later) and, if
we don't find that, look for /Developer.
Don't assume packagemaker is under $developer_path/usr/bin - with Xcode
4, you need to install Auxiliary Tools for Xcode to get PackageMaker,
and even that doesn't directly install the packagemaker command, so we
currently advise people to copy the PackageMaker binary to
/usr/bin/packagemaker.
svn path=/trunk/; revision=46957
puts them. If you choose to use MacPorts versions of the library, edit
the script or run it with -l.
Update the usage message and fix a typo.
svn path=/trunk/; revision=46955
appears at the end - if the user's installed an up-to-date version of
file to, for example, get pcap-ng files identified (Apple hasn't updated
file in *ages* - they're still in file 5.04!), it will report, for
example, "Mach-O 64-bit x86_64 executable" rather than "Mach-O 64-bit
executable x86_64" for an x86-64 binary.
svn path=/trunk/; revision=46954
Say "Pcap" rather than "Libpcap" - pcap format is used by WinPcap as
well (and it's also read and written by this library called Wiretap
:-)).
Add an additional entry for pcap-NG.
svn path=/trunk/; revision=42328
distribution.
To do this, however, requires renaming that directory because automake can't
handle files with spaces in their names.
svn path=/trunk/; revision=41040
Guy Harris