On Jun 28, 2016, at 4:25 PM, Chris Hanson wrote: >> On Jun 28, 2016, at 2:19 PM, Alex Zavatone <z...@mac.com> wrote: >> >> >>> On Jun 28, 2016, at 2:48 PM, Chris Hanson wrote: >>> >>>> On Jun 24, 2016, at 9:16 PM, Marco S Hyman <m...@snafu.org> wrote: >>>> >>>> Building a library, step 1: >>>> compile a bunch of .c, .m, .cc, .whatever files into .o files >>>> >>>> Building a library, step 2: >>>> Link all the .o files created in step 1 into a .a file >>> >>> This is subtly incorrect. >>> >>> On UNIX systems, step 2 is typically: >>> >>> Archive all the .o files created into step 1 into a .a file >>> >>> Unless configured specially, a static library on UNIX systems is typically >>> just an archive of *un-linked* .o files. They are neither linked against >>> the frameworks and libraries against which they were built, nor linked >>> against each other. All linkage (again, unless configured specially) >>> happens at the time the .a is used to produce a final linked product such >>> as an executable, bundle, or dylib. >>> >>> This can result in surprises when there are linkage requirements that >>> aren't satisfied by a downstream consumer of the .a file. >>> >>> -- Chris >> >> I just got this same build warning again today on a completely different >> project where we suddenly have 900 warnings that the library we are linking >> to was built for 9.3, but the app linking to it is expecting 7.0. > > That means the library or something it incorporated was built with a > Deployment Target of 9.3, while your app was built with a Deployment Target > of 7.0. > > Every object file records the Deployment Target with which it was built, > because it could have affected code generation. In a case like yours, the > library may not weak-link APIs introduced before 9.3 (say in 8.0) and thus > your app won't launch on that OS like you expect it to. > > As has been said, you need to look at the compile commands for the files that > make up the library, not the linkage of the library itself.
Yeah, I appreciate this but what's confusing the hell out of me is that in this occurrence of this issue I have 1 project that has 3 targets. Each target app is essentially a reskin. It's the same target, duplicated. They all target iOS 7 as the Deployment Target and all link to a lib. However, only one of them does not fire off 900 warnings about this. I suspect a borked upgrade to the linked lib, but I checked the header search paths, framework search paths, linked lib search paths and relinked all the linked libs, dependencies and libs we build from scratch. I'm thinking that there's a reference to a wrong lib in there and this is a misleading error message. Question. When building openSSL and beasties like pjSIP from the command line, is it possible to specify the iOS Deployment Target? Because that's what I'm AHA. So, The PJSIP .a target is being being properly built from all the compiled libs. And its deployment target is set to iOS 7.0. In the apps that link to that, there are bogus library search paths that search and find some old and left over ghosts of pjsip libs past. But then, the normal search paths do find the the one that I have built that targets 7.0 as a minimum OS. So, it runs, while linking to the the built lib, but also tries to link to "ghosts of code from Chennai past" and throws errors that - well, I'm not sure if they are the real error or not, but we have old paths pointing to linked code that should have been surgically excised and burnt at the stake. Jeebus. I've been awake too long for this. Thanks Chris. - Alex Zavatone _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
