Hi Martin,
> If the libpython would be simply linking to this library you then need
> libpython available in fixed location -
> like: /opt/freeware/lib/libpython2.6.a
>
> But for it to work you need libpython available at the default location
> before running your binary created by pyinstaller.
Not sure if you are right about this.
When I try to run the program on a machine with no Python
installation, it is missing "libpython2.6.a":
bash-3.00$ ./test
exec(): 0509-036 Cannot load program ./test because of the following
errors:
0509-150 Dependent module libpython2.6.a(libpython2.6.so)
could not be loaded.
0509-022 Cannot load module libpython2.6.a(libpython2.6.so).
0509-026 System error: A file or directory in the path name
does not exist.
Simply copying the file "libpython2.6.a" to the dist folder (for this
test I am using --onedir) changes the behaviour:
bash-3.00$ ./test
exec(): 0509-036 Cannot load program ./test because of the following
errors:
0509-130 Symbol resolution failed for MonitorBlockingSessions
because:
0509-136 Symbol mkdtemp (number 41) is not exported from
dependent module /usr/lib/libc.a(shr.o).
0509-192 Examine .loader section symbols with the
'dump -Tv' command.
So now it picks up the Python lib but runs into the next error (which
seems to be a too old version of the "libc".)
Also, it should be possible to change where an executable looks for
"statically" linked dynamic libs by using the linker option "-
blibpath". (However, it seems not to be necessary in this case.)
But...
I think I understand why the shared Python lib is not linked to the
bootloader but is loaded programmatically using "dlopen": in order to
work with different versions of Python, the code in the bootloader
cannot assume that all the possible symbols are available. If it did,
the linker would fail with older versions of Python where e.g.
"Py_IncRef" and "Py_DecRef" are not available.
Therefore, the library is loaded programmatically using "dlopen". Then
these two symbols are loaded optionally which you can see in "source/
common/launch.c" in function "int mapNames(HMODULE dll):
(Look for GETPROCOPT(...) below.)
int mapNames(HMODULE dll)
{
/* Get all of the entry points that we are interested in */
GETVAR(dll, Py_FrozenFlag);
<..snip..>
GETPROCOPT(dll, Py_IncRef);
GETPROCOPT(dll, Py_DecRef);
GETPROC(dll, PyImport_ExecCodeModule);
<..snip..>
if (!PI_Py_IncRef) PI_Py_IncRef = _EmulatedIncRef;
if (!PI_Py_DecRef) PI_Py_DecRef = _EmulatedDecRef;
return 0;
}
I think my approach now will be:
* Get the newest code from branch/1.5 (revision 1594 at the time of
writing).
* Apply my patches to this code (I know there will be some conflicts.)
* Keep the code I wrote for statically linking Python. It could be
used in the future maybe for
linking ActiveState Python.
* Keep the code you have added to the 1.5 branch in change 1586
regarding static linking of Python.
* Remove my comments regarding AIX in connection with static linking.
* In launch.c function "int loadPython()" add code for AIX to load the
shared lib correctly as
"libpython<ver>.a(libpythonx<ver>.so)".
After that I will have to address the problems with libc and libz.
Does it sound reasonable?
/Martin
--
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pyinstaller?hl=en.
