[Pythonmac-SIG] Re: shared libs in extension folder
Fri, 13 Oct 2000 10:22:10 -0700
>The reason to have an _alias_ there (as opposed to the real PythonCore
>library) is that this is about the only way that you can have two Python
>installations on the same disk. Because the application folder is searched
>before the Extensions folder I can have both 1.5.2 and 2.0 on my machine.
>Whenever I run PythonInterpreter from the 1.5.2 folder it'll pick up the
Dynamic (shared) libraries on the Mac have internal version numbers and
names that are independant of the file name (and vers resource). There
should be _no_ problem in having different versions of a shared library
in the Extensions folder at the same time.
To avoid the DLL hell that Windows suffers, you have to use the
versioning features that Apple put into its dynamic-library architecture.
It is slightly confusing, but you should be using it.
Please read the documentation and what I have to say later in this
quoting the documentation:
"To take a simple example, suppose that an application uses a single
import library. When the application is created, it is linked with some
version of that library. .... The version of the import library used at
link time is called the definition version of the library (because it
supplies the definitions of exported symbols, not the actual
implementation of routines and initialization of variables)."
"The essential requirement is that the implementation version of an
import library used at run time be compatible with the definition version
used at link time. The two versions do not need to be identical, but they
must satisfy the same programming interface. (The implementation can be a
superset of the definition library.)"
"Every import library contains three version numbers: the current version
number, the oldest supported definition version number, and the oldest
supported implementation version number. The two latter version numbers
are included to provide a way for the Code Fragment Manager to determine
whether a given definition version is compatible with a given
implementation version, if the current versions of the library and the
definition version used to link the application are not identical."
" IMPORTANT The current version number must always be greater than or
equal to both the oldest supported definition version number and the
oldest supported implementation version number."
If you're building a PythonCore 2.0 PPC shared library in CodeWarrior
that is _incompatible_ with Python 1.x, go to the Project Settings /
Linker / PPC PEF pane... the "Version Info" in that pane is NOT the
'vers' resource -- it allows you to specify the library (code-fragment)
The "Fragment Name" should be the shared-library-name excluding
version-number, trademark symbols and other frills. Call it "PythonCore".
"Current Version" (a single number) is the version of this library...
"Old Definition" (a single number) is the oldest supported lib-definition
supported by this library. If this library is incompatible with Python
1.x, then use the same number "200".
"Old Implementation" (a single number) is the oldest support
implementation supported by this library. If this library is incompatible
with Python 1.x, then use the sane number "200".
If you're building a PythonCore 1.5.2 shared library, and it is
_compatible_ with applications that were built against a hypothetical
PythonCore 1.4 and later, then your PPC PEF info would be:
"Fragment Name" == "PythonCore".
"Current Version" == "152"
"Old Definition" == "140"
"Old Implementation" == "140"
The hypothetical 1.4.0 PythonCore could also live in the extensions
folder with the 1.5.2 PythonCore and the 2.0 PythonCore. Obviously the
file names would have to be different. Since the file names are _not_
used by run-time linking, they can be anything, perhaps "Python Core
1.5.2", "PythonCore 1.4.0" and "PythonCore2".
Apps built against 2.0 would runtime-link with the 2.0 library because
that is the only one it is version-compatible with.
Apps built against 1.5.2 would runtime-link with the 1.5.2 PythonCore,
because the 2.0 PythonCore doesn't have version-compatbility, but the
1.5.2 PythonCore does.
Apps built against 1.4.0 would runtime-link with 1.5.2 PythonCore,
because it is more recent, but its version info claims compatibility with