XCode profiler throws errors processing ZZHeaders.h #25

Closed
jcollas opened this Issue Feb 26, 2013 · 16 comments

Projects

None yet

4 participants

@jcollas
jcollas commented Feb 26, 2013

I think this is because it's treating ZZHeaders.h as a C header file, not a C++ header file.

Screen Shot 2013-02-26 at 9 04 23 AM

@pixelglow
Owner

Hmm... were you including the ZZHeaders.h file in your project? The only public header files should be:

  • zipzap.h
  • ZZArchive.h
  • ZZArchiveEntry.h
  • ZZError.h
@jcollas
jcollas commented Feb 26, 2013

No, I wasn't. I think this is an artifact of running Xcode's 'profile' function, which might be less discriminating.

@rvsrvs
rvsrvs commented Feb 26, 2013

After experimenting a bit, I believe this is a clang bug. But it prevents us from profiling any apps which link zip zap.

@pixelglow
Owner

I can't reproduce the bug with a simple workspace that includes the zipzap project and has a command-line target for OS X. Perhaps you can submit a test workspace/project which shows it?

@rvsrvs
rvsrvs commented Feb 28, 2013

Ok, I've boiled it down. Below is the a clang command emitted by XCode when i try to compile zipzap for profilling with Instruments. I've stripped out everything which is specific to my project and I've done this on a completely clean clone of your repository.

I'm running the latest version of Xcode:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --version
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.1
Thread model: posix

Do the following:

git clone git@github.com:pixelglow/zipzap.git

cd zipzap

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c++ -arch i386 -fmessage-length=0 -Wno-trigraphs -fpascal-strings -Os -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wformat -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -w -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -Wno-c++11-extensions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk -fexceptions -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -Winvalid-offsetof -g -Wno-sign-conversion -fobjc-abi-version=2 -fobjc-legacy-dispatch -mios-simulator-version-min=5.1 -I./zipzap -DNS_BLOCK_ASSERTIONS=1 -fobjc-arc -DOS_OBJECT_USE_OBJC=0 -MMD -MT dependencies -MF/tmp/ZZOldArchiveEntry.d --serialize-diagnostics /tmp/ZZOldArchiveEntry.dia -c ./zipzap/ZZOldArchiveEntry.mm -o /tmp/ZZOldArchiveEntry.o

This last command results in:

n file included from ./zipzap/ZZOldArchiveEntry.mm:16:
./zipzap/ZZHeaders.h:11:6: error: expected identifier or '{'
enum class ZZCompressionMethod : uint16_t
^
./zipzap/ZZHeaders.h:17:6: error: expected identifier or '{'
enum class ZZFileAttributeCompatibility : uint8_t
^
./zipzap/ZZHeaders.h:28:2: error: unknown type name 'ZZFileAttributeCompatibility'
ZZFileAttributeCompatibility fileAttributeCompatibility;
^
./zipzap/ZZHeaders.h:31:2: error: unknown type name 'ZZCompressionMethod'
ZZCompressionMethod compressionMethod;
^
./zipzap/ZZHeaders.h:83:2: error: unknown type name 'ZZCompressionMethod'
ZZCompressionMethod compressionMethod;
^
./zipzap/ZZOldArchiveEntry.mm:97:50: error: use of undeclared identifier 'ZZCompressionMethod'
return _centralFileHeader->compressionMethod != ZZCompressionMethod::stored;
^
./zipzap/ZZOldArchiveEntry.mm:133:59: error: use of undeclared identifier 'ZZFileAttributeCompatibility'
return _centralFileHeader->fileAttributeCompatibility == ZZFileAttributeCompatibility::unix ? _centralFileHeader->externalFileAttributes >> 16 : 0;
^
7 errors generated.

Your help appreciated.

rvs

@jcollas
jcollas commented Feb 28, 2013

Ok, I figured it out. I'm using Xcode 4.6. The problem is clang wants the correct C++11 extension headers. I changed the zipzap.podspec to replace

s.xcconfig = { 'OTHER_CPLUSPLUSFLAGS' => '-std=gnu++11 -stdlib=libc++' }

With

s.xcconfig = {
'CLANG_CXX_LANGUAGE_STANDARD' => 'c++0x',
'CLANG_CXX_LIBRARY' => 'libc++'
}

and it works properly now. Do you have a problem making that change in the CocoaPods master repository?

@luisrecuenco

I'm also having those same problems. Looking forward to @rvsrvs response so you can update de podspec.

@jcollas
jcollas commented Mar 1, 2013

Luis,
If you temporarily make the change to the zipzap.podspec I suggest, you should be back in business. Once Glen gives me the ok, I'll check that change into the cocoapods master repo.

@pixelglow
Owner

All

Thanks for all your collaborative help -- it's good to see such uptake in the community! -- especially to @jcollas for nailing down the problem.

I'll update the Xcode project to language dialect C++11 and C99, and confirm it all still builds and tests OK. I believe such changes belong to the Xcode project and not the podspec, since this should benefit non-podspec users (such as myself).

If I understand this correctly, the s.xcconfig key adds to whatever Xcode settings are already in the project? If so, all that remains is to blank out or remove the key, then test the lot. I'll happily take any pull request for such a tested podspec.

@pixelglow
Owner

I've also updated the tags to the newest breaking API change i.e. 5.0 or 74daa74.

@jcollas
jcollas commented Mar 1, 2013

I have a 5.0 version of the podspec ready to check in, but your fix for updating the language dialect isn't in the 5.0 tag. If you can move the tag, I'll test and check in the 5.0 podspec.

@pixelglow
Owner

@jcollas, this was raised in #22 i.e. podspec versions tend to lag behind the actual tagged versions. Since I'm trying to follow Semantic Versioning, I only bump versions when there is some visible API change, and would prefer the tag to sit on the actual commit so people can see what constitutes that visible API change.

In the future I can update the podspec tag when I make the change, that makes the most sense going forward -- assuming that updating the version is trivial and not likely to need testing.

For now, if you prepare a 5.0.1 podspec, I can simultaneously accept the pull request and tag your commit with 5.0.1.

@jcollas
jcollas commented Mar 1, 2013

My understanding is that podspecs aren't versioned like repositories are. I can just add the s.xcconfig to the 4.0 and 5.0 releases of zipzap, but I'm concerned that some of the c++11 problems are actually resolved by xcode 4.6. I suggest just adding the s.xcconfing directives to the 4.0 and 5.0 podspecs, and leaving the code alone. Is this acceptable?

@luisrecuenco luisrecuenco referenced this issue in CocoaPods/Specs Mar 1, 2013
Merged

Add LRTVDBAPIClient 0.1 #1387

@jcollas
jcollas commented Mar 2, 2013

I checked in the s.xcconfig changes to the 4.0 and 5.0 zipzap podspecs. This will resolve the problems Luis is having with the lRTVDBAPIClient spec.

@pixelglow
Owner

@jcollas -- sorry, been busy with other work. The Xcode project itself should have C++11 and libc++ set since these are the correct settings going forward for iOS/Mac OS X work, it was an oversight for me to leave them out.

Would appreciate any updated podspec you have as a pull request.

@pixelglow
Owner

Closing due to lack of response.

@pixelglow pixelglow closed this Apr 6, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment