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 messageShow quoted text
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.
|
