-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow podspecs to indicate that they include categories #6
Comments
I’m wondering what the downsides are to just always adding the |
So apparently it will make the binary a bit fatter http://developer.apple.com/library/mac/#qa/qa1490/_index.html. Now the question is, how much does it add? And will most libPods builds have some dependency that enables it anyway, in which case (unless the size is a real issue) we might still be able to enable it by default anyways. |
Almost all specs add these flags atm, so I’m going to make this the standard. |
There is a downside that we are facing now with the all_load flag. Fat binaries including armv6 and armv7 do not work properly (duplicated class linking errors). Please, reopen #39 |
Add the '-ObjC -all_load' linker flags by default. Closes CocoaPods#6.
Reachability works on Mac, so don't restrict its platform
ADDED: UMengSocial 2.2.1
Has this issue been resolved for other people? I'm seeing it again even though I'm inheriting linking flags from CocoaPods... |
Same here |
I think the original proposal was good: If a Pod specifically sets Also the fact that most projects follow the bad practice of blindly adding |
I just want to clarify that if anyone else like myself have had any recent issues with like this https://t.co/YgP1Z8Xdqg |
Just installed a library via CocoaPods, and had to add the all_load flag to my project manually. . . Running Xcode 5.0.2 |
@jasperblues Very strange could you replicate in a demo project and open an issue referencing it? |
I have a demo project here: https://github.com/jasperblues/Typhoon-example, however I've since updated the .podspec to include: spec.xcconfig = { 'HEADER_SEARCH_PATHS' => '$(SDKROOT)/usr/include/libxml2', 'OTHER_LDFLAGS' => '-all_load' } However, in that project if you set the version of 'Typhoon' to 1.5.3 or earlier, you should be able to observe the issue. Is this enough info? Can you reproduce? Do you want to reopen this ticket or open a new one? |
@jasperblues It would be great if you could open a new one. |
Add the '-ObjC -all_load' linker flags by default. Closes #6.
…to square-fork * commit '079c4dc7fcdaa3da2c1be441e97fee82e19725da': Deduplicate test specs correctly from pod variants and targets
If a library includes Objective-C categories and requires them to function correctly, we should be able to specify this in the podspec and have the ObjC and all_load linker flags added automatically.
E.g.:
We can specify which system frameworks are required by adding them to OTHER_LDFLAGS but as this is a common case I'd like to see this as a natural part of the podspec file.
Something like:
The text was updated successfully, but these errors were encountered: