|
Re: Ensure Framework Links to static lib not dylib
Alex Zavatone
If we have more than one of us manually adding .a, there probably must be a process that does this automatically that we don’t know about.
toggle quoted messageShow quoted text
Any ideas?
On Dec 10, 2020, at 12:15 PM, James Walker <list2@...> wrote:On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@...> wrote:In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@...> wrote:I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a is something like:
|
|
|
|
Re: Ensure Framework Links to static lib not dylib
James Walker
On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@...> wrote:In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@...> wrote:I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a is something like:
|
|
|
|
Re: Ensure Framework Links to static lib not dylib
Sak Wathanasin
I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a is something like: ld .... -lFoo .... with the result that you (& I) have found. I tried adding various linker-extra flags to force it to use the .a, but in the end, I gave up and put the .a and .dylibs in separate directories (and changed the library search paths as needed). Regards
|
|
|
|
Ensure Framework Links to static lib not dylib
Sandor Szatmari
I have a Framework and am adding support to it from code located in an external library.
I have added the ‘.a’ version of the lib to the project (build phase link to…) I dragged it to the project navigator and added to appropriate target I have added include and search paths in target’s build settings Note: Both the ‘.a’ and dylib versions for the external resource are located in /usr/local/lib Everything builds and runs fine either in xcode or launched from outside xcode on the dev machine However, when I deploy the Framework to a non-dev machine it complains about the dylib not being present??? This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project Am I ‘doing it wrong’? How do I ensure the xcode target links my Framework to the static lib and not the dylib? Thanks in advance, Sandor
|
|
|
|
Re: Many new warnings after Xcode upgrade
Alex Zavatone
On Oct 29, 2020, at 7:16 PM, Quincey Morris <quinceymorris@...> wrote: That makes perfect sense. Is the header the umbrella header for the framework? Is so, then the < > brackets would make more sense since they would restrict searching for headers inside the framework (if I understand this correctly.) In that case, I’d expect just replacing the quotes with < > and rebuilding may be just what is needed. Cheers. Alex Zavatone
|
|
|
|
Re: Many new warnings after Xcode upgrade
Quincey Morris
I don’t have any special insights, but I think the warning is correct in that there has for some time been an (unwritten?) rule that the #imports *inside* a framework header should use angle brackets — for self-preservation.
toggle quoted messageShow quoted text
Again with no special knowledge, that makes sense to me because imports with double-quotes will search the framework *client’s* include paths first, and that’s almost certainly wrong if there are any symbol conflicts with what’s defined in the framework. OTOH, it’s hard to predict the effect of “fixing” the bracketing, because Xcode’s behavior here is somewhat inscrutable. All that said, my suggestion is as follows: 1. Commit your project as-is to the repository. 2. Apply all the “Double-quoted include …” warning fixits automatically. 3. Build and run the project. If that works, don’t lose any sleep. If something blows up, discard changes and silence the warnings, and don’t lose any sleep. :)
|
|
|
|
Re: Many new warnings after Xcode upgrade
Jim Adams
I was wondering about that myself. I have header files that are internal to the framework so shouldn’t be public.
From: <cocoa@apple-dev.groups.io> on behalf of "Graham Cox via groups.io" <graham@...>
EXTERNAL I just updated to XCode 12.1, and my project is throwing a lot of new warnings about “double-quoted include in framework header”. This appears to be because of the build setting “Quoted include in Framework Header”, which is now a recommended setting.
I can turn that off again, but what is this treally trying to tell me? These warnings appear to be bogus, in that yes, I’m building several frameworks as part of my workspace, but surely the files within those framework sources should be simple double quotes, not refer to the framework headers - after all, it’s the framework I’m building!
I’m confused, but perhaps it’s because my project structure is incorrect. But I don’t want to go and change a whole bunch of stuff before I properly understand what should be done here.
Example errors in the output — note, this framework is one I just use “as is”, I’m not even building it (Sparkle).
—Graham
|
|
|
|
Re: Many new warnings after Xcode upgrade
Alex Zavatone
I’d check to see why it expects < > angle brackets but it seems as if you’ve done all the research.
toggle quoted messageShow quoted text
This seems to point in the right direction. There are several links on that page that point to cases where people have resolved this. Cheers, Alex Zavatone
|
|
|
|
Many new warnings after Xcode upgrade
Graham Cox
I just updated to XCode 12.1, and my project is throwing a lot of new warnings about “double-quoted include in framework header”. This appears to be because of the build setting “Quoted include in Framework Header”, which is now a recommended setting.
I can turn that off again, but what is this treally trying to tell me? These warnings appear to be bogus, in that yes, I’m building several frameworks as part of my workspace, but surely the files within those framework sources should be simple double quotes, not refer to the framework headers - after all, it’s the framework I’m building! I’m confused, but perhaps it’s because my project structure is incorrect. But I don’t want to go and change a whole bunch of stuff before I properly understand what should be done here. Example errors in the output — note, this framework is one I just use “as is”, I’m not even building it (Sparkle).  —Graham
|
|
|
|
Re: Document versions browser shows windows in wrong stacking order/position
Steve Mills
On Oct 19, 2020, at 14:26:32, Steve Mills via groups.io <sjmills@...> wrote:
Turning off "Allow debugging during browsing versions" helps this work like it should, but still not perfectly. The windows tend to appear in the right order and location, but their rendering is still out of whack. I can't tell if "Enable user interface debugging" also makes a difference. -- Steve Mills Drummer, Mac geek
|
|
|
|
Document versions browser shows windows in wrong stacking order/position
Steve Mills
I'm trying to figure out why the versions browser is doing this weird thing with my windows. A video is linked below. The top-left corner of each window contains a timestamp for when the window gets created and the mod date of the actual file the document reads from. Notice how it ends up showing the oldest document on top after it loads all the version windows. Then as I go back through the versions, it keeps that oldest one on top. Then it starts showing the correct timestamps as I come back forward through versions. Any idea what I might be doing wrong? I'm letting NSDocument do nearly everything, and having changed any properties on the window that would screw this up.
https://www.armpitstudios.com/av/ScreenRecordingVersionsBrowserHorked.mov -- Steve Mills Drummer, Mac geek
|
|
|
|
Re: iCloud question: CloudKit vs. NSFileManager
Leo
Ok perfect - thanks Jens - that's exactly what I needed to know.
Leo
|
|
|
|
Re: iCloud question: CloudKit vs. NSFileManager
I would use NSFileManager. CloudKit is for storing a server-side database that supports queries, indexes and sharing … that's overkill for a simple settings file. Also, I believe if you use the NSFileManager API the user will be able to see the settings file in the Files app (or the Finder), which could be convenient. —Jens
|
|
|
|
iCloud question: CloudKit vs. NSFileManager
Leo
A question for those experienced in iCloud:
I want to implement some very basic iCloud tasks in my apps. Just to sync a few XML files that contain settings presets. So that the users can access their presets from anywhere.
The presets don't have to be kept in sync at any given moment - just updated when the user loads a specific preset.
As far as I understand, there are two ways to implement iCloud: CloudKit and NSFileManager iCloud methods.
It looks to me that NSFileManager is sufficient for what I need. Is that correct - or should I use CloudKit? Thanks for any info! Leo
|
|
|
|
NSMetadataQuery results property
Steve Mills
The shows this property:
@property (readonly, copy) NSArray *results; // this is for K-V Bindings, and causes side-effects on the query Anybody know what the cryptic comment means about side-effects? Just trying to figure out the best way to display the results (real-time as they come in) in an NSTableView. -- Steve Mills Drummer, Mac geek
|
|
|
|
Re: bonjour broken in iOS 14
Gerriet M. Denkmann
On 19 Sep 2020, at 07:51, Jens Alfke <jens@...> wrote:Correct. Older apps (build with some SDK < 14) get the default value for "Privacy - Local Network Usage Description” and do not require "Bonjour services” when run in iOS 14.On Sep 18, 2020, at 5:46 PM, Gerriet M. Denkmann <gerriet@...> wrote:Oh, right! It's the "Access local network" permission. I've seen that pop up. Gerriet.
|
|
|
|
Re: bonjour broken in iOS 14
Oh, right! It's the "Access local network" permission. I've seen that pop up. The Info.plist key must be required only if you build the app against the iOS 14 SDK, right? Otherwise that would break existing apps. —Jens
|
|
|
|
Re: bonjour broken in iOS 14
Gerriet M. Denkmann
On 19 Sep 2020, at 01:40, Jens Alfke <jens@...> wrote:I watched "WWDC 2020 - Support local network privacy in your app” and found out that in iOS 14 the Info.plist needs additional info:On Sep 18, 2020, at 2:34 AM, Gerriet M. Denkmann <gerriet@...> wrote: • Privacy - Local Network Usage Description if not present - then some default is used: “This app will be able to discover and connect to devices on the networks you use" • Bonjour services if this is missing, the app gets a .failed NWBrowser.State, with DNS Service Error: NoAuth(-65555) Also new in iOS 14: waiting: NWError: -65570: PolicyDenied = User has refused access to Local Network Gerriet.
|
|
|
|
Re: bonjour broken in iOS 14
I'm guessing your network environment includes a DNS server that supports DNS updates (i.e. wide-area Bonjour) but you don't have the credentials to push updates to the DNS server. This error probably only applies to the browser registration for that domain, not for the local-network domain. I.e. your app should still be working for local network browsing. If you only want to do local-network (mDNS) browsing, then use `domain: "local"` instead of `domain: nil`. —Jens Disclaimer: I've never used the "NW" classes, I'm just working off my knowledge of Bonjour.
|
|
|
|
bonjour broken in iOS 14
Gerriet M. Denkmann
This worked up to iOS 13:
let serviceType = "_Gmd-BackGround._tcp." let parameters = NWParameters() parameters.includePeerToPeer = true let browser = NWBrowser(for: .bonjour(type: serviceType, domain: nil), using: parameters ) browser.stateUpdateHandler = { (newState: NWBrowser.State) in print(“\newState”) } browser.start(queue: queue) But in iOS 14 the stateUpdateHandler gets a .failed NWBrowser.State, with DNS Service Error: NoAuth(-65555) How can this be fixed? Gerriet.
|
|
|
