User Profile

Our main Apple account holder initiated the process to generate a certificate for the "Developer ID Installer" option. To finish that, he needed a Certificate Signing Request file, which I generated on the Mac itself. He then used that file to create a .cer file, which I imported on the Mac by double clicking the file. But I'm not sure what to do next, and I'm wondering if we missed something or did something wrong. For one thing, when I click on what I think is the certificate in Keychain Access, a message in red says it's not trusted. Plus what exactly do I need to specify in the codesign command for it to access what is (or should be) in the key chain? The documentation says it wants a "signing identity", but what exactly is that? What should I be looking for in the key chain? Note that when I created the Certificate Signing Request file, I specified my Apple login. When our main account holder created the .cer file, he of course would have done it using his login. These two logins are both supposed to be associated with the same team, but could that be part of the difficulty?

I'm not actually using Xcode for anything. It's there because it supposedly has the pieces to do this build. The build simply uses makefiles that invoke a gcc binary.This Mac was recently upgraded to OS X v10.10.5 from an older version (I forget what it was) by a contractor. Prior to the upgrade, we had a configuration that worked for doing this build. The configuration had everything in the /Developer hierarchy, which the contractor says is the hierarchy that Xcode used to create. So, to your question about whether Xcode 7 can build an iOS dylib, I would think it can, since whatever older version of Xcode we had before was able to do it.I can copy the old /Developer hierarchy from the backup to the main disk, but with the newer version of OS X it no longer works. The contractor suggested installing Xcode v7.2.1, which is the newest Xcode that can be used with OS X v10.10.5. We did the install, but where the old /Developer hierarchy had a gcc tool chain that was explicitly for iOS on ARM, the new /Applications/Xcode.app/Contents/Developer hierarchy doesn't have such a tool chain.The contractor suggested just using /usr/bin/gcc, but that, as you can see, produces code for OS X on ARM, not iOS on ARM. The contractor pretty much admitted that issues like this are out of his area of expertise.The previous configuration was put in place by someone who is no longer with our company, so now I have the task of trying to configure this Mac so this build will once again succeed. Unfortunately my knowledge of doing development work on the Mac is very limited.The build procedures (makefiles) are the same as we used before with the previous configuration that worked, albeit with a couple of directories changed to match the new Xcode version. It seems that we're missing a gcc that is specifically designed for creating code for iOS on ARM.So...how do we get that cross compiler tool chain? I noticed that there are .dmg files named DeveloperDiskImage.dmg in the iPhone directories within Xcode. Do I need to do something with one of those?I did start the Xcode app (never used it before) and chose to create a new Xcode project. For iOS it presents me with a choice of Application or Framework & Library. For my purposes Framework & Library seems more appropriate. But then it gives me a choice between Cocoa Touch Framework and Cocoa Touch Static Library. I have no idea what either of those is.And in regard to linker options, since you mentioned that, our linker options include -arch armv7 and -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk. But specifying these with /usr/bin/gcc results in code for OS X on ARM instead of iOS on ARM. The previous configuration specified both of these but used a gcc apparently specifically designed to create code for iOS on ARM.