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

To: cocoa@apple-dev.groups.io

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.