While compiling
OTPublisherSettings *settings = [[OTPublisherSettings alloc] init];
getting compiler error.
Bad receiver type 'int32_t' (aka 'int')
Using the latest Xcode, happening on all unmodified sample apps, looked in lib headers dir under Pods, Found the OTPublisher.h and OTPublisherKit.h headers, cannot seem to find the OTPublisherSettings class. Am I missing something?
I just did a fresh install of sample apps with pod install without any errors. Did you see any issues when you were trying to install the SDK using cocoapods. What SDK version are you using ?
Related
I wrote a Swift App with Xcode6 Beta 2 that does some networking using CFNetwork classes such as NSURLRequest and NSHTTPURLResponse.
The App works just fine with iOS 8, still, when I try to run it on an iOS 7 device or in the simulator running iOS 7, I get the following error when starting the App:
dyld: Symbol not found: _OBJC_CLASS_$_NSHTTPURLResponse
Referenced from: /Users/patrick/Library/Developer/CoreSimulator/Devices/B0A61F43-A67C-4803-8F5D-77C3972107BE/data/Applications/E0C7C89F-9EEE-4893-BE5B-FCC224F2855D/CheckYourWeather.app/CheckYourWeather
Expected in: /Applications/Xcode6-Beta2.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk/System/Library/Frameworks/CFNetwork.framework/CFNetwork
in /Users/patrick/Library/Developer/CoreSimulator/Devices/B0A61F43-A67C-4803-8F5D-77C3972107BE/data/Applications/E0C7C89F-9EEE-4893-BE5B-FCC224F2855D/CheckYourWeather.app/CheckYourWeather
I've done some research and found out that it's a linking problem. Still, I know that the classes I'm using are already available in iOS 7.
I also tried to add the CFNetwork.framework to the frameworks in the project settings and set it to optional, which only caused the App to crash during runtime.
The confusing part for me is: I wrote a Test App and just pasted my code I used in the main app into it and it worked just fine. Therefore the code is probably not the problem.
Deleting the App from the Simulator/Device, make a clean on the project and deleting Xcode's DerivedData haven't solved the problem.
Update:
Here's the code that causes the crash:
extension NSURLRequest {
class func plainPostRequest(url: NSURL, httpBody: String) -> NSURLRequest {
let urlRequest = NSMutableURLRequest(URL: url)
urlRequest.HTTPMethod = "POST"
urlRequest.HTTPBody = httpBody.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)
urlRequest.setValue("text/plain", forHTTPHeaderField: "Content-Type")
return urlRequest
}
}
But that's just an example. Any use of CFNetwork classes causes the App to crash during start.
This is a known bug with the iOS 8 SDK. As a workaround, move Foundation.framework before CFNetwork.framework in the list of frameworks to link to in the project settings.
For me just moving the Foundation.framework before CFNetwork.framework doesn't work. I need to close and reopen the project for it to work.
I was able to fix the problem by creating a new project and copying all my classes and assets there. Unfortunately I couldn't find out what the actual source of the problem was.
Any alternative solutions are greatly appreciated!
Moving Foundation.framework would not help so after further investigation the further method helped me.
I was able to resolve the problem by adding main.m file at Build Phases -> Compile Sources
Apparently it couldn't find the main.m file.
I have a Cocoa program with deployment target 10.7, using the latest (10.8) SDK, I run it on 10.7.5 with XCode 4.6.2. In it I work with NSURLs with no problem whatsoever, everything works fine. One method I use is the NSURL method:
[newURL checkResourceIsReachableAndReturnError:&error]
with newURL a pointer to aNSURL. So far so good.
However, when I compile and run this, on a mac mini with Mountain Lion installed the following warning appears:
CFURLResourceIsReachable failed because it was passed this URL which has no scheme
and some other things now go wrong as well, such as
[dict setObject:url forKey:[url path]],
with dict a NSMutableDictionary and url a NSURL, the url simply is not added anymore to the dict. Strange isn't it? Did I miss a change in how NSURLs work from OS X 10.7 to 10.8?
Apologies if this already has been discussed here (I could not find it), thanks for looking at this question,
Marijn
I keep running into EXC_BAD_ACCESS when calling [obj JSONString] method in the following code and I don't know why. I have tried turning on Zombie Objects but nothing different happens.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSDictionary *obj = #{
#"id": #1,
#"date": #"11/07/2012",
#"companyInfo": #"Company Details",
#"customerInfo": #"Customer Details",
#"taxRate": #0
};
NSLog(#"%#", obj);
NSLog(#"%#", [obj JSONString]);
// Other stuff here
}
I am running Lion. I have just upgraded to Xcode 4.4 and am using CocoaPods 0.9.2 to install JSONKit. I have tried both the 1.4 and 1.5pre versions of JSONKit to no avail.
I am using the latest OS X SDK (10.8) with a deployment target of 10.6 (it must deploy to 10.6). I have also tried the 10.7 SDK but the results are the same. The 10.6 SDK is no longer available so I cannot test that.
clang --version shows:
Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix
The application compiled and ran correctly when I was using Xcode 4.3.
It turned out that the problem was that CocoaPods does not remove the existing JSONKit files when running pod install. I'm using version 1.5pre and the code executes correctly.
We have a problem with updating a helper tool with SMJobBless that has been puzzling us for days now.
We are developing an application for which at some point we need to perform administrative tasks (loading/unloading a kext). We are also using the keychain to store account information for our application.
For the administrative tasks, we use a helper tool that is installed using SMJobBless with which we communicate using DO over Mach ports (with NSConnection).
In the helper tool:
// use our bundle id as our service name
NSString* name = [[NSBundle mainBundle] bundleIdentifier];
launch_data_t checkinRequest = launch_data_new_string(LAUNCH_KEY_CHECKIN);
launch_data_t checkinResponse = launch_msg(checkinRequest);
launch_data_t machServicesDict = launch_data_dict_lookup(checkinResponse, LAUNCH_JOBKEY_MACHSERVICES);
launch_data_t machPort = launch_data_dict_lookup(machServicesDict, [name UTF8String]);
mach_port_t mp = launch_data_get_machport(machPort);
launch_data_free(checkinResponse);
launch_data_free(checkinRequest);
NSMachPort *receivePort = [[NSMachPort alloc] initWithMachPort:mp];
NSConnection *server = [NSConnection connectionWithReceivePort:receivePort sendPort:nil];
In the app:
NSConnection *conn = [NSConnection connectionWithRegisteredName:HELPER_BUNDLE_IDENTIFIER host:nil];
id proxyServerObject = [conn rootProxy];
if(conn && proxyServerObject) {
return [proxyServerObject someMethod];
}
return NO;
We sign both the application and the helper tool using a codesign certificate from Thawte. So far, everything works like a charm. The helper tool is installed and we can communicate with it using DO; our kext is loaded and unloaded successfully.
The problem starts when we try to update our helper tool. We use the info dictionary of the installed tool and the bundled tool in our app bundle to check whether an update of the tool is required and call SMJobBless again to perform the update.
After the SMJobBless call, the following lines appear in the Console:
6/19/12 10:31:24.000 AM kernel: CODE SIGNING: cs_invalid_page(0x104e17000): p=74362[OURAPP] clearing CS_VALID
6/19/12 10:31:24.000 AM kernel: CODE SIGNING: cs_invalid_page(0x10d0de000): p=74364[OURAPPHELPER] clearing CS_VALID
After this, the application is unable to read the application password from our keychain item, the function SecKeychainItemCopyContent returns errSecAuthFailed (-25293). However, no error is reported if we manually verify the code signature of our installed helper tool or application bundle using codesign -vvvv PATH_TO_TOOL_OR_BUNDLE.
The tool and application are signed outside of the Xcode environment and the contents are not altered after the signing process.
We have found one other post that describes a similar situation, but that question is still unanswered.
A related issue might be SMJobBless returning error 4098.
We are testing on OSX 10.7.4.
Anyone faced similar issues or is there something obvious that we are doing wrong?
This is due to a bug related to how SMJobBless replaces the helper tool on disk. In particular, it modifies the binary in place rather than taking the common approach of writing to a temporary file and then renaming it over top of the destination. The effect of this is that if the binary is in memory, the modifications to the file change the memory pages backing the file, invalidating their code signature. I've written up a bug report about this as rdar://problem/13514523. I'd encourage you to file your own if you've not done so already.
A possible workaround may be to have your application ask the helper tool to remove itself from disk before you use SMJobBless to upgrade it. This should result in SMJobBless copying to a new file on disk, bypassing the issue.
i made an App that was submitted to the Mac AppStore. For some reasons, they refused it, because it was installing a helper tool using the SMJobBless API.
As this helper tool isn't necessary for most of the App's functionality, i have removed it, and my application got accepted.
So right now, i am packaging a standalone installer for the helper tool that would be downloadable on the internet.
However, after i have installed the files in place, the helper tool refuses to run... The helper tool just has a plist that goes into /Library/LaunchDaemons and a binary that goes into /Library/PrivilegedHelperTools.
Now i'm wondering, what exactly is SMJobBless doing more than moving files into place? Is it registering my tool with launchctl? i tried various things, to manually add it to launchctl, without success: the helper tool just exits after requesting it's checkin request.
The helper tool just contains that:
#autoreleasepool {
launch_data_t req = launch_data_new_string(LAUNCH_KEY_CHECKIN);
launch_data_t resp = launch_msg(req); // AT THIS POINT, RESP IS NULL. Why?
launch_data_t machData = launch_data_dict_lookup(resp, LAUNCH_JOBKEY_MACHSERVICES);
launch_data_t machPData = launch_data_dict_lookup(machData, [kHelperBundleName UTF8String]);
mach_port_t mp = launch_data_get_machport(machPData);
launch_data_free (resp);
launch_data_free (req);
// Prepare connexion.
NSMachPort *rp = [[NSMachPort alloc] initWithMachPort:mp];
PrivilegedHelperProxy
*phProxy = [[[PrivilegedHelperProxy alloc] init] autorelease];
NSConnection *con = [NSConnection connectionWithReceivePort:rp sendPort:nil];
[rp release];
[con setRootObject:phProxy];
[[NSRunLoop currentRunLoop] run];
}
return EXIT_SUCCESS;
This service was running flawlessly when getting installed via the SMJobBless API, and the root proxy was accessible from within my APP...
So what would be the required steps for my installer to get this helper tool properly working, as it would with calls to the SMJobBless API?
Thanks,
Pierre.
Solved. The PList entry for the helper tool wasn't including any ProgramArguments (This didn't seem to be an issue with the SMJobBless API). After adding those to the PList, the helper tool can correctly run, and the installer registers it correctly.
Thanks anyways!
Pierre.