blob: 164d5a7597ad038de53607f688889e0d4b2f2e25 [file] [log] [blame]
class-dump is a utility for examining the Objective-C segment of
Mach-O files. It generates the @interface and @protocol declarations
for classes, categories and protocols.
Version 2 is a re-implementation of Eric P. Scott's class-dump, and
works with the frameworks in Openstep 4.x.
The class-dump version 2.1.5 package includes source that should
compile on Mac OS X, Mac OS X Server, Openstep, and
Nextstep 3.3 with Foundation. This package includes the binary
compiled for Mac OS X:
class-dump-2.1.5-bs.tar.gz (Mac OS X)
Most of the changes since version 2.1.2 have been fixes for Mac OS X,
so I haven't updated the Mac OS X Server, Openstep and Nextstep
packages:
class-dump-2.1.2-PI-bs.tar.gz (Mac OS X Server)
class-dump.2.1.2.m.NIS.bs.tar.gz (Openstep)
class-dump.2.1.2.NIHS.bs.tar.gz (Nextstep)
These are all available from by website at:
http://www.omnigroup.com/~nygard/Projects/index.html
Differences between 2.1.5 and 2.1.4
- Compiled on Mac OS X. The release notes say "Do Not Use Pre-GM
Compilers to Build Software for Mac OS X", so I've recompiled this.
- No changes other than the version number and README.
Differences between 2.1.4 and 2.1.3
- Carl Lindberg made some changes that make class-dump work
better on Mac OS X Public Beta:
- It's a little better about backward compatibility with old
frameworks that still work on Public Beta.
- It fixes most of the syntax errors we were getting when
parsing types. (We were having trouble with union types.)
- It now understands framework install names and the framework
search path, so you should be able to run it on apps or
frameworks where the install name of the frameworks is not where
the framework exists in the filesystem. The Omni frameworks,
for example, change the install name.
- It will search for an app executable in the Contents/MacOS
directory of the app wrapper that Mac OS X uses if you just
use the path to the main app wrapper.
- You can set the ClassDumpDebugFrameworkPaths environment variable
to see the steps it's going through to find the frameworks. It
spits out a lot of stuff, but it may be useful for someone. With
zsh, you can do this:
ClassDumpDebugFrameworkPaths=YES class-dump /System/Applications/MailViewer.app
Differences between 2.1.3 and 2.1.2
- James McIlree made these changes to get class-dump running on
Mac OS X DP4:
- The OS X mach-o files keep some information in the __TEXT
__cstring section. I've made a small set of tweeks to cause
class-dump to look in the correct segment and section.
- The build on OS X defines NS_TARGET_MAJOR as 5, this needs
to be set in order to get the new code.
Differences between 2.1.2 and 2.1.1
- Tom Hageman has provided the changes to make it work with object
files and bundles. In the previous version, the output was empty.
- It shouldn't crash if there are fewer types than it expects while
formatting a method. This is most likely triggered by incompatible
current versions of frameworks.
Differences between 2.1.1 and 2.1.0
- Compiles under Rhapsody, Openstep and Foundation based Nextstep
3.3. Tom Hageman provided the changes to get it working with
Nextstep 3.3 and compiled it quad-fat.
- Under Rhapsody, the -C option now takes egrep style regular
expressions to match categories and protocols. It will still
work as before with text strings, but you can, for example,
specify -C 'View|Window' to match classes with both strings.
Differences between 2.1.0 and 2.0
- The -a option has been split into -a, which just shows instance
variable offsets, and -A, which shows method addresses.
(Suggested by Charles Lloyd.)
- Protocol definitions are all printed at the beginning of the
output for each file. Duplicate protocol definitions are no
longer shown.
- New option, -S, to sort the output. Protocols are sorted by
name. Classes and categories are sorted by name. Class and
instance methods are each sorted by name. (Suggested by
Charles Lloyd.)
- When the -S option is not used, the method definitions are
printed out reversed from the order they are found in the
Mach-O file. This should reflect the order they are declared
in the original source file.
- The effect of the -C option has changed. It now matches
category and protocol names instead of just class names.
(Carl Lindberg pointed out that categories should also be matched.)
- Corrected output when the target file doesn't have an
Objective-C segment.
- An 'id *' type should now be printed correctly.
- Fixed printing of pointers to arrays.
- Fixed printing of multi-dimensional arrays.
- Made #ifdefs of LC_PREBOUND_DYLIB and LC_LOAD_DYLIB independant
for compiling under 3.3 (Suggested by Carl Lindberg.)
- This now uses the Foundation framework, so it may not work with
Nextstep 3.x.
- flex is no longer required.
- The version number of class-dump is now included in the output.
Visible differences between version 2 and version 1
- class-dump works with framework based files (the whole point of this
exercise!)
- The class declaration shows the adopted protocols.
- Protocol definitions are shown before (rather than after) the class
declaration.
- New option, -r, to recursively expand frameworks and fixed VM
shared libraries.
- A comment is generated to show the file where the classes are
defined. This is helpful when using the -r option.
- New option, -s, to use "char *" instead of "STR".
Known problems
- The Nexttime bundles under 4.1 seem to have invalid pointers for some of
the method names (they point into the __meth_var_types section instead of
the __meth_var_names section) and therefore generate errors. This may be
caused from being compiled against a different "current version" of a
framework than what is available on the current system. For example:
4.1 Nexttime bundles: compatibility version 129.0.0, current version 153.0.0
4.1 Foundation framework: compatibility version 129.0.0, current version 154.0.0
This also shows up in the AppleMenuOptions.app under Rhapsody DR2.
- A couple old applications have type strings that the parser can't handle.
Compiling
Mac OS X
This should build directly from Project Builder. There are
a couple of harmless warnings.
Openstep, Nextstep
Bison is required to compile this. There should be no warnings.
To compile first copy the PB.project and Makefiles from one
of the Nextstep or Openstep directories into the
main source directory and then build it.
Comments and suggestions are welcomed.
Steve Nygard <nygard@omnigroup.com>