Date   

Re: Ensure Framework Links to static lib not dylib

Sandor Szatmari
 

Thanks for everyone’s thoughts… I really appreciate it.

I would think, that’s where I went wrong apparently :D, that Xcode should respect explicit configurations, which is what I thought I had done, and that this should be possible.

I’ll examine the linker logs… I’ll try the explicit, full path, linker flag and see if that works. Short of that I’ll just modify the installation of the external lib.

I agree Alex, there’s got to be some special sauce to add here.

Sandor

On Dec 10, 2020, at 13:34, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

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.

Any ideas?

On Dec 10, 2020, at 12:15 PM, James Walker <list2@jwwalker.com> wrote:



On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:


On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
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).
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.








Ensure Framework Links to static lib not dylib

Jonathan Prescott
 



Begin forwarded message:

From: Jonathan Prescott <jprescott12@...>
Subject: Re: [cocoa-dev] Ensure Framework Links to static lib not dylib
Date: December 10, 2020 at 1:50:14 PM EST

Put the “Other Linker Flags” variable (OTHER_LDFLAGS) in an .xcconfig file, if I understand what you mean by “a process that does this automatically”.  
Jonathan

On Dec 10, 2020, at 1:31 PM, Alex Zavatone via groups.io <zav@...> wrote:

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.

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:



On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@...> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project


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).

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.










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.

Any ideas?

On Dec 10, 2020, at 12:15 PM, James Walker <list2@jwwalker.com> wrote:



On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:



On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
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).
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.




Re: Ensure Framework Links to static lib not dylib

James Walker
 

On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:



On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
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).
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.


Re: Ensure Framework Links to static lib not dylib

Sak Wathanasin
 



On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@...> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project


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
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


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@rivergatesoftware.com> wrote:

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.

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.

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.

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. :)

On Oct 29, 2020, at 05:45 , Jim Adams via groups.io <jim.adams@...> wrote:

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@...>
Reply-To: "cocoa@apple-dev.groups.io" <cocoa@apple-dev.groups.io>
Date: Wednesday, October 28, 2020 at 8:02 PM
To: "cocoa@apple-dev.groups.io" <cocoa@apple-dev.groups.io>
Subject: [cocoa-dev] Many new warnings after Xcode upgrade
 
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).
 
<image001.png>
 
—Graham
 
 



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@...>
Reply-To: "cocoa@apple-dev.groups.io" <cocoa@apple-dev.groups.io>
Date: Wednesday, October 28, 2020 at 8:02 PM
To: "cocoa@apple-dev.groups.io" <cocoa@apple-dev.groups.io>
Subject: [cocoa-dev] Many new warnings after Xcode upgrade

 

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.

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

On Oct 28, 2020, at 7:01 PM, Graham Cox <graham@...> wrote:

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).

<Screen Shot 2020-10-29 at 10.53.51 am.png>

—Graham




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=mac.com@groups.io> wrote:

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
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

 



On Oct 12, 2020, at 10:19 PM, Leo <leo.r@...> wrote:

As far as I understand, there are two ways to implement iCloud: CloudKit and NSFileManager iCloud methods.

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@mooseyard.com> wrote:

On Sep 18, 2020, at 5:46 PM, Gerriet M. Denkmann <gerriet@mdenkmann.de> 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:
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.
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.

Gerriet.


Re: bonjour broken in iOS 14

 



On Sep 18, 2020, at 5:46 PM, Gerriet M. Denkmann <gerriet@...> 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:

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@mooseyard.com> wrote:

On Sep 18, 2020, at 2:34 AM, Gerriet M. Denkmann <gerriet@mdenkmann.de> wrote:

But in iOS 14 the stateUpdateHandler gets a .failed NWBrowser.State, with DNS Service Error: NoAuth(-65555)
I watched "WWDC 2020 - Support local network privacy in your app” and found out that in iOS 14 the Info.plist needs additional info:

• 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.

61 - 80 of 1378