On 22/10/2014 17:50, Bill Somerville wrote: > The complexity of making object code available might be not worth the > trouble and dynamic linking may be easiest IMHO. AFAIK dynamic linking > is the way that this is done in almost all proprietary products. The practicalities of dynamic linked vary from platform to platform.
On Windows and Linux one needs to compile and link the executable against the oldest versions of the dynamic libraries that are to be supported. On Windows it is probable that the executable will be delivered bundled with the DLLs, on Linux the bundling of shared libraries is not practical (probably impossible) so this is where a decision about the oldest system and compiler support libraries to be linked against has to be made. This probably boils down to deciding the oldest distribution version to support and doing the compile and link on that system. The reason for doing this is that newer generations of shared libraries can introduce new APIs but will also support older APIs, usually using API symbol versioning. Compiling and linking against the newer shared libraries risks referencing newer APIs that are not backwards compatible. On Mac the approach is different. Apple provide SDKs that allow compiling and linking against older system library versions. So on Mac you compile and link against the newest SDK you wish to support and specify a compiler and linker option that sets the oldest OS version supported. The resulting executable may run on OS versions newer then the SDK version it was built with but that is not guaranteed since APIs can be removed by Apple. Apple also provide a way of bundling libraries with an executable which resolves any issues of non-system library compatibility (this in effect is similar to on Windows where the DLL loader looks in the directory of the executable first to resolve any dynamic references). I'm afraid there are no simple solutions to these matters. 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel