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
