[Pythonmac-SIG] Re: shared libs in extension folder

[kjray]

>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 
>1.5.2 

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 
message:
<http://developer.apple.com/techpubs/mac/PPCSoftware/PPCSoftware-41.html#HE
ADING41-42>

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) 
version information.

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... 
say, "200"

"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 
1.4.0.