Date   

Loading tiff files

tridiak
 

Is there any way to programmatically load tiff image files?
Or does there exist a library that can do such?

Mark


Re: folder entitlements EPERM

Jack Brindle
 

You can open the desired System Preference Security Pane from your app to help the user with making the selection you need. Many apps have pretty cool dialogs that not only direct the user to the pane, but also point out exactly what needs to be done in that pane.

Do a web search for MacOS System Preference Links to find a listing of the URLs. As an example, the link for Full Disk is:
x-apple.systempreferences:com.apple.preference.security?Privacy_AllFiles

The interesting Objective-C code looks like:

[[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:@"x-apple.systempreferences:com.apple.preference.security?Privacy_AllFiles”]];

Enjoy!

Jack


On Jan 25, 2021, at 5:58 PM, Gerriet M. Denkmann <gerriet@...> wrote:



On 26 Jan 2021, at 08:28, Jack Brindle via groups.io <jackbrindle@...> wrote:

Not just app store apps, on Catalina and especially Big Sur, all apps.

The suggestion is to have the user drag the app to the “Full Disk Access” panel of the Security & Privacy’s Privacy pane. Then you should be able to get anywhere you’d like.

Thanks a lot! This is the perfect solution for my app:

System Preferences →  Security & Privacy → Privacy → Full Disk Access (bottom of left scroll view) → add or enable app in right scroll view.

Gerriet.


Jack


On Jan 25, 2021, at 3:36 PM, Jens Alfke <jens@...> wrote:



On Jan 25, 2021, at 9:12 AM, Gerriet M. Denkmann <gerriet@...> wrote:

There are quite a few folders, which behave absolutely normal using the Finder, but when my App tries to do:
open(folderPath, O_RDONLY)
it gets an EPERM error: "Operation not permitted”.

When my App  shows an OpenPanel (with this un-opened folder), and the user clicks ok, then the open() works just fine.

Isn't that just the normal behavior of the app sandbox? Sandboxed apps aren't allowed to access arbitrary areas of the filesystem, unless the user has implicitly given permission by navigating to a file/folder in an Open panel, or dropping a document, etc.

—Jens







Re: folder entitlements EPERM

Alex Zavatone
 

Check out how Carbon Copy Cloner does it if you haven’t seen it recently.

On Jan 25, 2021, at 7:58 PM, Gerriet M. Denkmann <gerriet@mdenkmann.de> wrote:



On 26 Jan 2021, at 08:28, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

Not just app store apps, on Catalina and especially Big Sur, all apps.

The suggestion is to have the user drag the app to the “Full Disk Access” panel of the Security & Privacy’s Privacy pane. Then you should be able to get anywhere you’d like.
Thanks a lot! This is the perfect solution for my app:

System Preferences → Security & Privacy → Privacy → Full Disk Access (bottom of left scroll view) → add or enable app in right scroll view.

Gerriet.


Jack


On Jan 25, 2021, at 3:36 PM, Jens Alfke <jens@mooseyard.com> wrote:



On Jan 25, 2021, at 9:12 AM, Gerriet M. Denkmann <gerriet@mdenkmann.de> wrote:

There are quite a few folders, which behave absolutely normal using the Finder, but when my App tries to do:
open(folderPath, O_RDONLY)
it gets an EPERM error: "Operation not permitted”.

When my App shows an OpenPanel (with this un-opened folder), and the user clicks ok, then the open() works just fine.
Isn't that just the normal behavior of the app sandbox? Sandboxed apps aren't allowed to access arbitrary areas of the filesystem, unless the user has implicitly given permission by navigating to a file/folder in an Open panel, or dropping a document, etc.

—Jens





Re: folder entitlements EPERM

Gerriet M. Denkmann
 

On 26 Jan 2021, at 08:28, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

Not just app store apps, on Catalina and especially Big Sur, all apps.

The suggestion is to have the user drag the app to the “Full Disk Access” panel of the Security & Privacy’s Privacy pane. Then you should be able to get anywhere you’d like.
Thanks a lot! This is the perfect solution for my app:

System Preferences → Security & Privacy → Privacy → Full Disk Access (bottom of left scroll view) → add or enable app in right scroll view.

Gerriet.


Jack


On Jan 25, 2021, at 3:36 PM, Jens Alfke <jens@mooseyard.com> wrote:



On Jan 25, 2021, at 9:12 AM, Gerriet M. Denkmann <gerriet@mdenkmann.de> wrote:

There are quite a few folders, which behave absolutely normal using the Finder, but when my App tries to do:
open(folderPath, O_RDONLY)
it gets an EPERM error: "Operation not permitted”.

When my App shows an OpenPanel (with this un-opened folder), and the user clicks ok, then the open() works just fine.
Isn't that just the normal behavior of the app sandbox? Sandboxed apps aren't allowed to access arbitrary areas of the filesystem, unless the user has implicitly given permission by navigating to a file/folder in an Open panel, or dropping a document, etc.

—Jens


Re: folder entitlements EPERM

Jack Brindle
 

Not just app store apps, on Catalina and especially Big Sur, all apps.

The suggestion is to have the user drag the app to the “Full Disk Access” panel of the Security & Privacy’s Privacy pane. Then you should be able to get anywhere you’d like.

Jack


On Jan 25, 2021, at 3:36 PM, Jens Alfke <jens@...> wrote:



On Jan 25, 2021, at 9:12 AM, Gerriet M. Denkmann <gerriet@...> wrote:

There are quite a few folders, which behave absolutely normal using the Finder, but when my App tries to do:
open(folderPath, O_RDONLY)
it gets an EPERM error: "Operation not permitted”.

When my App  shows an OpenPanel (with this un-opened folder), and the user clicks ok, then the open() works just fine.

Isn't that just the normal behavior of the app sandbox? Sandboxed apps aren't allowed to access arbitrary areas of the filesystem, unless the user has implicitly given permission by navigating to a file/folder in an Open panel, or dropping a document, etc.

—Jens


Re: folder entitlements EPERM

Jon Gotow
 

On Jan 25, 2021, at 5:16 PM, Ben Kennedy <ben-groups@zygoat.ca> wrote:

Presumably you could solicit access to the root of the volume once, and thereafter build URLs for the relevant subpaths based on the security-scoped URL returned by the panel.

Per https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW20 :
I got rejected from the App Store for doing that. However, there are lots of apps in the App Store that prompt for access to the root level of a disk using an Open dialog and get approved, so you may get lucky.

In my case, I didn't bother to fight it, as it was just for a free app (Go64). I released it directly on my website instead.

- Jon


Re: folder entitlements EPERM

Ben Kennedy
 

On 25 Jan 2021, at 9:12 am, Gerriet M. Denkmann <gerriet@mdenkmann.de> wrote:

When my App shows an OpenPanel (with this un-opened folder), and the user clicks ok, then the open() works just fine.

The problem: there might be a lot of these folders, and clicking dozens of OpenPanel becomes tedious rather fast.
Presumably you could solicit access to the root of the volume once, and thereafter build URLs for the relevant subpaths based on the security-scoped URL returned by the panel.

Per https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW20 :

When a user of your app specifies they want to use a file or a folder, the system adds the associated path to your app’s sandbox. Say, for example, a user drags the ~/Documents folder onto your app’s Dock tile (or onto your app’s Finder icon, or into an open window of your app), thereby indicating they want to use that folder. In response, the system makes the ~/Documents folder, its contents, and its subfolders available to your app.
-ben


Re: folder entitlements EPERM

 



On Jan 25, 2021, at 9:12 AM, Gerriet M. Denkmann <gerriet@...> wrote:

There are quite a few folders, which behave absolutely normal using the Finder, but when my App tries to do:
open(folderPath, O_RDONLY)
it gets an EPERM error: "Operation not permitted”.

When my App  shows an OpenPanel (with this un-opened folder), and the user clicks ok, then the open() works just fine.

Isn't that just the normal behavior of the app sandbox? Sandboxed apps aren't allowed to access arbitrary areas of the filesystem, unless the user has implicitly given permission by navigating to a file/folder in an Open panel, or dropping a document, etc.

—Jens


folder entitlements EPERM

Gerriet M. Denkmann
 

macOS 11.1

There are quite a few folders, which behave absolutely normal using the Finder, but when my App tries to do:
open(folderPath, O_RDONLY)
it gets an EPERM error: "Operation not permitted”.

When my App shows an OpenPanel (with this un-opened folder), and the user clicks ok, then the open() works just fine.

The problem: there might be a lot of these folders, and clicking dozens of OpenPanel becomes tedious rather fast.

So: is there some special entitlement, like: "com.apple.security.folders which usually need user action.read-only” ?

Or any ideas, how to handle this?

Gerriet.


Re: item based NSBrowser

Gerriet M. Denkmann
 

On 4 Jan 2021, at 21:58, Bill Cheeseman <wjcheeseman@comcast.net> wrote:

Back when I was first starting to develop my UI Browser product, https://pfiddlesoft.com/uibrowser, there were three helpful Objective-C Cocoa code examples for NSBrowser from Apple: SimpleCocoaBrowser, ComplexBrowser, and AnimatedTableView. I haven't looked at them in a long time, but I'm sure you can find them somewhere.
I found the SimpleCocoaBrowser (thanks very much for your hint) and it works just fine.

The BrowserDelegate (called AppController in the sample code) implements 4 required + 1 optional methods:
- (id)rootItemForBrowser:(NSBrowser *)browser (optional)
- (NSInteger)browser:(NSBrowser *)browser numberOfChildrenOfItem:(id)item
- (id)browser:(NSBrowser *)browser child:(NSInteger)index ofItem:(id)item
- (BOOL)browser:(NSBrowser *)browser isLeafItem:(id)item
- (id)browser:(NSBrowser *)browser objectValueForItem:(id)item

Then I rewrote the BrowserDelegate in Swift, and again I got:

*** Illegal NSBrowser delegate (<SimpleBrowser.SwiftBrowserDelegate: 0x600001221260>). Must implement browser:willDisplayCell:atRow:column: and either browser:numberOfRowsInColumn: or browser:createRowsForColumn:inMatrix:

The reason:

I implemented:
func isLeafItem(_ item: Any?) -> Bool { false } ← wrong

instead of:
func browser(_ browser: NSBrowser, isLeafItem item: Any?) -> Bool { false }

A rather stupid mistake.
But the error message was not very helpful.

Thanks again for your help!

Gerriet.


Re: item based NSBrowser

Bill Cheeseman
 

Back when I was first starting to develop my UI Browser product, https://pfiddlesoft.com/uibrowser, there were three helpful Objective-C Cocoa code examples for NSBrowser from Apple: SimpleCocoaBrowser, ComplexBrowser, and AnimatedTableView. I haven't looked at them in a long time, but I'm sure you can find them somewhere.

UI Browser implements six NSBrowserDelegate methods that I describe in my source code comments as "required NSBrowser item-based delegate methods." They are: -rootItemForBrowser:, -browser:numberOfChildrenOfItem:, -browser:child:ofItem:, -browser:isLeafItem:, -browser:willDisplayCell:atRow:column:, and -browser:objectValueForItem:. You left two of them out of your list of "required" item-based methods.

UI Browser also implements a number of optional NSBrowserDelegate methods, including: -browser:numberOfRowsInColumn:, -browser:shouldShowCellExpansionForRow:column:, and -browserDidScroll:.

Bill Cheeseman

On Jan 3, 2021, at 1:31 AM, Gerriet M. Denkmann <gerriet@...> wrote:

So: how do I create an "item based NSBrowser" with a delegate using "item data source methods” ?


On Jan 3, 2021, at 1:31 AM, Gerriet M. Denkmann <gerriet@...> wrote:

So: how do I create an "item based NSBrowser" with a delegate using "item data source methods” ?


item based NSBrowser

Gerriet M. Denkmann
 

Xcode tells me that:
'matrix(inColumn:)' was deprecated in macOS 10.10: Use the item based NSBrowser instead

And when I use parentForItemsInColumn it crashes with:
parentForItemsInColumn: is not supported for browsers with matrix delegates.

NSBrowser.h says:
" Note: the matrix based NSBrowser is deprecated in Mac OS 10.10. New code should use the item based interface.”

These seem to be the "matrix based NSBrowser” methods:
- (NSInteger)browser:(NSBrowser *)sender numberOfRowsInColumn:(NSInteger)column;
- (void)browser:(NSBrowser *)sender createRowsForColumn:(NSInteger)column inMatrix:(NSMatrix *)matrix;

"Alternatively, implement all of the following methods”
- (NSInteger)browser:(NSBrowser *)browser numberOfChildrenOfItem:(nullable id)item API_AVAILABLE(macos(10.6));
- (id)browser:(NSBrowser *)browser child:(NSInteger)index ofItem:(nullable id)item API_AVAILABLE(macos(10.6));
- (BOOL)browser:(NSBrowser *)browser isLeafItem:(nullable id)item API_AVAILABLE(macos(10.6));
- (nullable id)browser:(NSBrowser *)browser objectValueForItem:(nullable id)item API_AVAILABLE(macos(10.6));


So I tried:

func browser(_ browser: NSBrowser, numberOfChildrenOfItem item: Any?) -> Int { 5 }
func browser(_ browser: NSBrowser, child index: Int, ofItem item: Any?) -> Any { "test” }
func isLeafItem(_ item: Any?) -> Bool { false }
func browser(_ browser: NSBrowser, objectValueForItem item: Any?) -> Any? { item }

But when I run this, I get:

*** Illegal NSBrowser delegate (<TestBrowser.AppDelegate: 0x600003c19300>). Must implement browser:willDisplayCell:atRow:column: and either browser:numberOfRowsInColumn: or browser:createRowsForColumn:inMatrix:

and my browser is completely empty.

So: how do I create an "item based NSBrowser" with a delegate using "item data source methods” ?

Gerriet.


Re: Core Graphics: creating an image mask from a PDF?

Jim
 

On Dec 14, 2020, at 8:17 PM, Graham Cox <graham@mapdiva.com> wrote:

I am using Core Graphics. I have an image as a PDF resource that I want to use as a mask - specifically, the PDF only contains black and white graphics as vectors. I have code that can turn that into a CGImageRef as a normal bitmap (to any desired size I want, which is why I start with a PDF file), but the bitmap image I end up with is, of course, black and white. I actually want to draw that in any colour I choose by using a mask image and a fill colour.

Core Graphics has a function CGImageMaskCreate(), which takes a bunch of the usual parameters but only works with a data provider. There is no PDF data provider (AFAIK).

The bitmap image code works by creating a CGBitmapImageContext, drawing the PDF into it, then using CGBitmapContextImageCreate() to obtain the bitmap. But there’s no mask equivalent of this approach. There is also no function to create a mask image from a bitmap image.

Can anyone think of a solution here? Either to create a mask image from a PDF, or a way to draw a black and white bitmap colourised at will. The latter may be possible using CGImageCreateWithMaskingColors(), but the documentation isn’t very clear and the Quartz drawing guide seems to suggest it’s more for background removal than what I need here. If anyone has an example of how to use it (if it’s even appropriate here) that would be great too.
I’ve used CoreImage (CIBlendWithMask filter) to use a mask.

https://developer.apple.com/library/archive/documentation/GraphicsImaging/Reference/CoreImageFilterReference/index.html#//apple_ref/doc/filter/ci/CIBlendWithMask

CoreImage makes it easy to create solid-color images as well.

CIImage *bkgImage = [CIImage imageWithColor:[CIColor colorWithRed:0 green:0 blue:0 alpha:0]];

Alternatively, if you want to stick with the CoreGraphics functions, you can use ImageIO to create a data output of your CGImageRef bitmap that you should be able to feed into CGImageMaskCreate().

Jim Crate


Core Graphics: creating an image mask from a PDF?

Graham Cox
 

Hi all,

I am using Core Graphics. I have an image as a PDF resource that I want to use as a mask - specifically, the PDF only contains black and white graphics as vectors. I have code that can turn that into a CGImageRef as a normal bitmap (to any desired size I want, which is why I start with a PDF file), but the bitmap image I end up with is, of course, black and white. I actually want to draw that in any colour I choose by using a mask image and a fill colour.

Core Graphics has a function CGImageMaskCreate(), which takes a bunch of the usual parameters but only works with a data provider. There is no PDF data provider (AFAIK).

The bitmap image code works by creating a CGBitmapImageContext, drawing the PDF into it, then using CGBitmapContextImageCreate() to obtain the bitmap. But there’s no mask equivalent of this approach. There is also no function to create a mask image from a bitmap image.

Can anyone think of a solution here? Either to create a mask image from a PDF, or a way to draw a black and white bitmap colourised at will. The latter may be possible using CGImageCreateWithMaskingColors(), but the documentation isn’t very clear and the Quartz drawing guide seems to suggest it’s more for background removal than what I need here. If anyone has an example of how to use it (if it’s even appropriate here) that would be great too.


—Graham


Re: Ensure Framework Links to static lib not dylib

Sandor Szatmari
 

Thanks Jack, yes, your point is well taken… but, these are in house production apps/frameworks and we have a long running well establish deployment design that works well…

The structure is as follows

Cocoa App/Frameworks… (with statically linked external libs) are hosted on /Network/Applications and /Network/Frameworks. These shares are pushed out via the OpenDirectory master. Then all clients who are part of the domain automagically have all the components they need with deployment being limited to a single point. Keeping the frameworks out of the apps means replacing one copy of the framework if making a change that does not require pushing out the apps too. I know it’s mostly a moot point… and certainly the horse is dead at this point. We do embed our frameworks within app for qc purposes for updates/new features. This makes an encapsulated bundle for testing that finds it’s frameworks internally before looking at the other runtime framework search paths.

For external libraries that can change version based on an OS update/Security Update, I link them statically so there is no question the frameworks/apps are using the correct external resources for which QA/testing has been performed and certified. So, this is the point at which we embed, albeit statically linked embedding, code from one source inside another source.

Sandor

On Dec 10, 2020, at 14:29, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

I wonder if you might want to embed the library in your application. That might make it more future-proof.

Jack


On Dec 10, 2020, at 11:14 AM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

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.















Re: Ensure Framework Links to static lib not dylib

Jack Brindle
 

I wonder if you might want to embed the library in your application. That might make it more future-proof.

Jack

On Dec 10, 2020, at 11:14 AM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

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.











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.

121 - 140 of 1454