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.















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.











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.








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.










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.




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.


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


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