the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?
Could anybody help me to create this library. Mine (from python2.0.tar)
generates a segmentation violation. maybe some bad compile flags.
Thanks,
Alain.
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?
NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/
Jutta
Jutta Steinhoff a écrit :
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/Jutta
Same!!!
configure file is not properly written to create the shared library!
Other idea?
thanks,
Alain.
Alain Bonnefoy wrote:
Jutta Steinhoff a écrit :
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/Jutta
Same!!!
configure file is not properly written to create the shared library!
Other idea?
Question to all:
Has anyone intention to realize the DLL version of Python 2.1 ???
We have actually no time for it…
Jutta
Jutta Steinhoff wrote:
Alain Bonnefoy wrote:
Jutta Steinhoff a écrit :
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/Jutta
Same!!!
configure file is not properly written to create the shared library!
Other idea?
Question to all:
Has anyone intention to realize the DLL version of Python 2.1 ???
We have actually no time for it…
I might do that if people send me postcards in advance, lol 
Igor Kovalenko wrote:
Jutta Steinhoff wrote:
Alain Bonnefoy wrote:
Jutta Steinhoff a écrit :
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/Jutta
Same!!!
configure file is not properly written to create the shared library!
Other idea?
Question to all:
Has anyone intention to realize the DLL version of Python 2.1 ???
We have actually no time for it…
I might do that if people send me postcards in advance, lol >
Igor, check your mailbox for the first post card!
…and next interesting step would be PyQt 
how many postcards for PyQT ??
Happy programming
Jutta
Igor Kovalenko a écrit :
Jutta Steinhoff wrote:
Alain Bonnefoy wrote:
Jutta Steinhoff a écrit :
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/Jutta
Same!!!
configure file is not properly written to create the shared library!
Other idea?
Question to all:
Has anyone intention to realize the DLL version of Python 2.1 ???
We have actually no time for it…
I might do that if people send me postcards in advance, lol >
- igor
Good luck !!!
I tried, and I stopped quickly!
2.0 is quite simple. some declarations like local externs are not well understood
by our gcc version, but nothing very complex.
I still have some problems with gcc flags to generate a good libpython2.0.so. If
you could help me ;o).
Thanks,
Alain.
Alain Bonnefoy wrote:
Igor Kovalenko a écrit :
Jutta Steinhoff wrote:
Alain Bonnefoy wrote:
Jutta Steinhoff a écrit :
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/Jutta
Same!!!
configure file is not properly written to create the shared library!
Other idea?
Question to all:
Has anyone intention to realize the DLL version of Python 2.1 ???
We have actually no time for it…
I might do that if people send me postcards in advance, lol >
- igor
Good luck !!!
I tried, and I stopped quickly!
2.0 is quite simple. some declarations like local externs are not well understood
by our gcc version, but nothing very complex.I still have some problems with gcc flags to generate a good libpython2.0.so. If
you could help me ;o).
… use Python 2.1
Armin
Thanks,
Alain.
Previously, Alain Bonnefoy wrote in qdn.public.porting:
Igor Kovalenko a écrit :
Jutta Steinhoff wrote:
Alain Bonnefoy wrote:
Jutta Steinhoff a écrit :
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/Jutta
Same!!!
configure file is not properly written to create the shared library!
Other idea?
Question to all:
Has anyone intention to realize the DLL version of Python 2.1 ???
We have actually no time for it…
I might do that if people send me postcards in advance, lol >
- igor
Good luck !!!
I tried, and I stopped quickly!
2.0 is quite simple. some declarations like local externs are not well understood
by our gcc version, but nothing very complex.I still have some problems with gcc flags to generate a good libpython2.0.so. If
you could help me ;o).
It probably SEGVs for you because code was not compiled with -fpic. Here is quote from Python FAQ:
3.30. Why is the Python interpreter not built as a shared library?
(This is a Unix question; on Mac and Windows, it is a shared library.)
It’s just a nightmare to get this to work on all different platforms.
Shared library portability is a pain. And yes, I know about GNU libtool
– but it requires me to use its conventions for filenames etc, and it
would require a complete and utter rewrite of all the makefile and
config tools I’m currently using.
In practice, few applications embed Python – it’s much more common to
have Python extensions, which already are shared libraries. Also,
serious embedders often want total control over which Python version and
configuration they use so they wouldn’t want to use a standard shared
library anyway. So while the motivation of saving space when lots of
apps embed Python is nice in theory, I doubt that it will save much in
practice. (Hence the low priority I give to making a shared library.)
For Linux systems, the simplest method of producing libpython1.5.so
seems to be (originally from the Minotaur project web page,
http://mini.net/pub/ts2/minotaur.html):
make distclean
./configure
make OPT=“-fpic -O2”
mkdir .extract
(cd .extract; ar xv ../libpython1.5.a)
gcc -shared -o libpython1.5.so .extract/*.o
rm -rf .extract
I tried that with 2.1 and it appears to produce .so. But since I’m not Python fan I did not bother checking if it really works. Let me know if it still crashes…
I think Python maintainers are ought to drop their lame excuses toward libtool though.
Igor Kovalenko a écrit :
Previously, Alain Bonnefoy wrote in qdn.public.porting:
Igor Kovalenko a écrit :Jutta Steinhoff wrote:
Alain Bonnefoy wrote:
Jutta Steinhoff a écrit :
Alain Bonnefoy wrote:
the Python 2.0 package from TUCOWS seems to have a problem because the
dyn-load directory which would contain libpython2.0.so has a 0 size.
Does anybody know who made the package?NO,
but if you want a working version (and sources) incl. TCL/TK and
IDLE (Python IDE) have a look to Armin’s port:
http://sourceforge.net/projects/pyqnx/Jutta
Same!!!
configure file is not properly written to create the shared library!
Other idea?
Question to all:
Has anyone intention to realize the DLL version of Python 2.1 ???
We have actually no time for it…
I might do that if people send me postcards in advance, lol >
- igor
Good luck !!!
I tried, and I stopped quickly!
2.0 is quite simple. some declarations like local externs are not well understood
by our gcc version, but nothing very complex.I still have some problems with gcc flags to generate a good libpython2.0.so. If
you could help me ;o).
It probably SEGVs for you because code was not compiled with -fpic. Here is quote from Python FAQ:3.30. Why is the Python interpreter not built as a shared library?
(This is a Unix question; on Mac and Windows, it is a shared library.)
It’s just a nightmare to get this to work on all different platforms.
Shared library portability is a pain. And yes, I know about GNU libtool
– but it requires me to use its conventions for filenames etc, and it
would require a complete and utter rewrite of all the makefile and
config tools I’m currently using.In practice, few applications embed Python – it’s much more common to
have Python extensions, which already are shared libraries. Also,
serious embedders often want total control over which Python version and
configuration they use so they wouldn’t want to use a standard shared
library anyway. So while the motivation of saving space when lots of
apps embed Python is nice in theory, I doubt that it will save much in
practice. (Hence the low priority I give to making a shared library.)For Linux systems, the simplest method of producing libpython1.5.so
seems to be (originally from the Minotaur project web page,
http://mini.net/pub/ts2/minotaur.html> ):make distclean
./configure
make OPT=“-fpic -O2”
mkdir .extract
(cd .extract; ar xv ../libpython1.5.a)
gcc -shared -o libpython1.5.so .extract/*.o
rm -rf .extractI tried that with 2.1 and it appears to produce .so. But since I’m not Python fan I did not bother checking if it really works. Let me know if it still crashes…
I think Python maintainers are ought to drop their lame excuses toward libtool though.
- Igor
Ok now to generate the libpython2.0.so and it seems to work. I have a problem now during make install when the scripts tries to execute python -tt
/usr/local/lib/python2.0/compilall.py /usr/local/python2.0. Lot of errors, it begins by ‘import site failed; use -v for traceback’
all compilation failed with:
Sorry: AttributeError: ‘string’ object has no attribute ‘replace’.
Any idea?
make and make install are ok for your 2.1 ?
Thanks,
Alain.
Alain Bonnefoy wrote:
Igor Kovalenko a écrit :
[ clip ..]
Ok now to generate the libpython2.0.so and it seems to work. I have a problem now during make install when the scripts tries to execute python -tt
/usr/local/lib/python2.0/compilall.py /usr/local/python2.0. Lot of errors, it begins by ‘import site failed; use -v for traceback’
all compilation failed with:
Sorry: AttributeError: ‘string’ object has no attribute ‘replace’.Any idea?
Have you set PYTHONHOME ?
make and make install are ok for your 2.1 ?
Yes.
Armin
Armin Steinhoff a écrit :
Alain Bonnefoy wrote:
Igor Kovalenko a écrit :
[ clip ..]
Ok now to generate the libpython2.0.so and it seems to work. I have a problem now during make install when the scripts tries to execute python -tt
/usr/local/lib/python2.0/compilall.py /usr/local/python2.0. Lot of errors, it begins by ‘import site failed; use -v for traceback’
all compilation failed with:
Sorry: AttributeError: ‘string’ object has no attribute ‘replace’.Any idea?
Have you set PYTHONHOME ?
before doing a make install ?!?
make and make install are ok for your 2.1 ?
Yes.
Armin
I’m interesting if you also have the libpython2.1.so
Alain.
Alain Bonnefoy wrote:
[ clip ..]
Have you set PYTHONHOME ?
before doing a make install ?!?
Yes … when I remember right.
make and make install are ok for your 2.1 ?
Yes.
Armin
I’m interesting if you also have the libpython2.1.so
Yes, I had the the shared lib … my problem was the dynamic
loading. I got always the message ‘module not available’ or so.
Armin
Hope I can go back into the details next weeks …