On Dec 10, 2020, at 11:14 AM, Sandor Szatmari <admin.szatmari.net@...> 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@...> 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.