Date
1 - 8 of 8
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
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
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
James Walker
On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@...> wrote: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.On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@...> wrote: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:
This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
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).
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?
toggle quoted message
Show quoted text
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: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.On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@...> wrote: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:
This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
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).
Jonathan Prescott
Begin forwarded message:From: Jonathan Prescott <jprescott12@...>Subject: Re: [cocoa-dev] Ensure Framework Links to static lib not dylibDate: December 10, 2020 at 1:50:14 PM ESTPut the “Other Linker Flags” variable (OTHER_LDFLAGS) in an .xcconfig file, if I understand what you mean by “a process that does this automatically”.JonathanIf 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.
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
toggle quoted message
Show quoted text
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: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.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: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:
This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
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).
Jack Brindle
I wonder if you might want to embed the library in your application. That might make it more future-proof.
Jack
toggle quoted message
Show quoted text
Jack
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.
SandorOn 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: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.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: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:
This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
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).
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
toggle quoted message
Show quoted text
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@...> wrote:
I wonder if you might want to embed the library in your application. That might make it more future-proof.
JackOn 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.
SandorOn 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: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.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: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:
This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
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).