In the original discussion, the installation directory (where libraries and
their associated files) are installed has absolutely zero effect on binding
choices for picking up the actual DLL used for a particular shared library.
The directory layout is actually a convenience for a *developer* who wishes to
simply use the latest, CoApp packaged version.
Shared library binding is handled by WinSXS, where a developer chooses a
particular version of a library to bind to. So, for example let's say that you
want to compile up Python with OpenSSL 0.98h . You can specifically choose the
path for the import library by including the version, and you are bound to that
version. Now, there is one slight caveat.
WinSXS allows a publisher of a shared library to set the policy of the shared
library so that if they put in a bug fix, but do alter the binary interface
(ABI) then at run time, the application picks up the latest ("Most
recommended") *binary compatible* version of the library.
This means that you bind Python to OpenSSL 0.98h. A bug is found, the publisher
of OpenSSL releases 0.98k, and since the ABI hasn't changed, the major & minor
versions haven't changed [0][98], just the revision [k]. So once the new
library is installed, Python will use it.
*This is the behavior we want*
However, when OpenSSL 0.99a ships, by virtue of having the minor # changed
[98]->[99] the policy should not forward use on to the new version, and Python
would continue to use 0.98k.
This is extremely important, because when we're using shared libraries, it's
the author's/publisher's responsibility to provide security and bug-fix
updates in a binary compatible way, and it's the consumer's responsibility to
use the libraries in a consistent fashion so we preserve that intent.
Yes, this relinquishes control from the consumer to the publisher, but that is
a better balance anyway.
So, if you really really really need to bind to a very specific version, and
you are dead set against preserving the shared library model, while it is
possible to force bind dynamically to a specific version, what you are really
wanting is to be statically bound.
Lemme say that again: If you don't' intend to work with shared libraries in the
prescribed way, you really want to be statically bound, and should select the
foo_a.lib. You will actually gain additional performance, and will still be
able to work in-process with other applications using the dynamic library
version without collision.
Shared libraries need to be used in a shared-responsibility fashion.
>> This is an interesting discussion point, I think. I can understand the
>> rationale for having a non-versioned, well-known path pointing to the latest
>> version of something (i.e. openssl symlink to openssl-0.98j). However, I
>> also think there's a case for projects that would never want to rely on an
>> arbitrary version of a component they depend upon.
>> Take Python, for instance. For every Windows release, I can tell you
>> exactly
>> which version of SQLite, OpenSSL, zlib etc that was used, because we version
>> control all our dependencies (http://svn.python.org/view/external/), and are
>> explicit about which versions get used in a given release.
>> The reason this is important is because that all testing and development is
>> done with everyone using the exact same version of dependencies. If you
>> happen to build a local copy of a Python release but drop in a different
>> version of SQLite, you end up with a release that's divergent from the
>> 'official' build (at the very least, it'll be untested).
>> So, I'd argue there's a use case for projects to be explicit about which
>> versions of other components they rely upon for a given release, and that
>> there should be a way for CoApp to support that.
>> If we move towards building, signing and distributing projects on behalf
>> of their owners, perhaps one of our pre-requisites would be that the project
>> needs to elicit the exact version of their dependencies that they did all
>> their release testing/development against.
Thoughts?
Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on
Windows.
-----Original Message-----
From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net
[mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On
Behalf Of Gordon Schumacher
Sent: Wednesday, April 14, 2010 6:38 AM
To: [email protected]
Subject: Re: [Coapp-developers] Another kind of package
On 4/14/2010 6:58 AM, Trent Nelson wrote:
> So, I'd argue there's a use case for projects to be explicit about
> which versions of other components they rely upon for a given release,
> and that there should be a way for CoApp to support that.
> If we move towards building, signing and distributing projects on behalf of
> their owners, perhaps one of our pre-requisites would be that the project
> needs to elicit the exact version of their dependencies that they did all
> their release testing/development against.
>
I can certainly see the value in that, on one hand... but on the other hand,
the last project I was on had a substantial list of third-party library
dependencies. The obvious "building block" libraries got pulled in by quite a
number of different components - libpng, libxml, MySQL, OpenSSL, and Qt all
depend on it. I was also building some of the tools we needed, so that they
too would be in the self-contained toolchain, so Subversion, Ruby, Perl, and
indeed Python also all had a zlib dependency. For the sake of sanity I
explicitly did not want to attempt to deal with multiple versions of these
libraries - not least because some of these libraries could get shipped to the
customer, potentially over a slow online update.
I actually ended up doing quite a fair bit of "extra" work in order to /not/
use the pre-bundled versions - in some cases, it was more or less enforced by
the project's Win32 build system, hence why a great lot of my script was
running "sed" or some such against build scripts!
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
