J'essaie de compiler cpython (3.2.2) pour une plateforme non standard
(QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé sur
un os.
Voici un petit script de test :
A l'exécution, j'obtiens la sortie suivante :
> python3 test.py
test running...
start thread
Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ?
Python n'est vraiment pas locace.
En exécutant "python3 -vvvvvv test.py", c'est pas mieux ; j'ai juste
"Memory fault" comme compte rendu.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Damien Wyart
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard (QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé sur un os.
A l'exécution, j'obtiens la sortie suivante : > python3 test.py test running... start thread Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ? Python n'est vraiment pas locace.
Un Google rapide ne donne pas grand'chose de récent, donc ça ressemble à un problème "exotique". A moins qu'il y ait d'autre réponses ici par la suite, je pense que tu auras des conseils plus précis en exposant le problème sur la liste de développement de Python, ou en ouvrant un bug.
Les développeurs du coeur de Python pourront t'indiquer plus précisément comment approfondir le débogage.
Sinon, tu peux toujours essayer d'utiliser multiprocessing si ton appli n'a pas un besoin strict de threads (les threads ont des limitations par rapport au GIL). Mais c'est un contournement qui ne résout pas le problème de départ...
-- DW
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard
(QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé
sur un os.
A l'exécution, j'obtiens la sortie suivante :
> python3 test.py
test running...
start thread
Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ?
Python n'est vraiment pas locace.
Un Google rapide ne donne pas grand'chose de récent, donc ça ressemble
à un problème "exotique". A moins qu'il y ait d'autre réponses ici par
la suite, je pense que tu auras des conseils plus précis en exposant le
problème sur la liste de développement de Python, ou en ouvrant un bug.
Les développeurs du coeur de Python pourront t'indiquer plus précisément
comment approfondir le débogage.
Sinon, tu peux toujours essayer d'utiliser multiprocessing si ton appli
n'a pas un besoin strict de threads (les threads ont des limitations par
rapport au GIL). Mais c'est un contournement qui ne résout pas le
problème de départ...
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard (QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé sur un os.
A l'exécution, j'obtiens la sortie suivante : > python3 test.py test running... start thread Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ? Python n'est vraiment pas locace.
Un Google rapide ne donne pas grand'chose de récent, donc ça ressemble à un problème "exotique". A moins qu'il y ait d'autre réponses ici par la suite, je pense que tu auras des conseils plus précis en exposant le problème sur la liste de développement de Python, ou en ouvrant un bug.
Les développeurs du coeur de Python pourront t'indiquer plus précisément comment approfondir le débogage.
Sinon, tu peux toujours essayer d'utiliser multiprocessing si ton appli n'a pas un besoin strict de threads (les threads ont des limitations par rapport au GIL). Mais c'est un contournement qui ne résout pas le problème de départ...
-- DW
Nicolas
Le 24/05/2013 09:56, Damien Wyart a écrit :
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard (QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé sur un os.
A l'exécution, j'obtiens la sortie suivante :
python3 test.py
test running... start thread Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ? Python n'est vraiment pas locace.
Un Google rapide ne donne pas grand'chose de récent, donc ça ressemble à un problème "exotique". A moins qu'il y ait d'autre réponses ici par la suite, je pense que tu auras des conseils plus précis en exposant le problème sur la liste de développement de Python, ou en ouvrant un bug.
Les développeurs du coeur de Python pourront t'indiquer plus précisément comment approfondir le débogage.
Sinon, tu peux toujours essayer d'utiliser multiprocessing si ton appli n'a pas un besoin strict de threads (les threads ont des limitations par rapport au GIL). Mais c'est un contournement qui ne résout pas le problème de départ...
multiprocessing est une solution pour les applis que j'écris moi-même. Mais c'est plus lourd et il y a beaucoup de bibliothèques qui utilisent les threads. A commencer par les serveurs HTTP. Et c'est justement pour faire du WEB que j'ai besoin de python.
Je joue avec les options de configuration pour l'instant.
Le 24/05/2013 09:56, Damien Wyart a écrit :
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard
(QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé
sur un os.
A l'exécution, j'obtiens la sortie suivante :
python3 test.py
test running...
start thread
Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ?
Python n'est vraiment pas locace.
Un Google rapide ne donne pas grand'chose de récent, donc ça ressemble
à un problème "exotique". A moins qu'il y ait d'autre réponses ici par
la suite, je pense que tu auras des conseils plus précis en exposant le
problème sur la liste de développement de Python, ou en ouvrant un bug.
Les développeurs du coeur de Python pourront t'indiquer plus précisément
comment approfondir le débogage.
Sinon, tu peux toujours essayer d'utiliser multiprocessing si ton appli
n'a pas un besoin strict de threads (les threads ont des limitations par
rapport au GIL). Mais c'est un contournement qui ne résout pas le
problème de départ...
multiprocessing est une solution pour les applis que j'écris moi-même.
Mais c'est plus lourd et il y a beaucoup de bibliothèques qui utilisent
les threads. A commencer par les serveurs HTTP. Et c'est justement pour
faire du WEB que j'ai besoin de python.
Je joue avec les options de configuration pour l'instant.
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard (QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé sur un os.
A l'exécution, j'obtiens la sortie suivante :
python3 test.py
test running... start thread Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ? Python n'est vraiment pas locace.
Un Google rapide ne donne pas grand'chose de récent, donc ça ressemble à un problème "exotique". A moins qu'il y ait d'autre réponses ici par la suite, je pense que tu auras des conseils plus précis en exposant le problème sur la liste de développement de Python, ou en ouvrant un bug.
Les développeurs du coeur de Python pourront t'indiquer plus précisément comment approfondir le débogage.
Sinon, tu peux toujours essayer d'utiliser multiprocessing si ton appli n'a pas un besoin strict de threads (les threads ont des limitations par rapport au GIL). Mais c'est un contournement qui ne résout pas le problème de départ...
multiprocessing est une solution pour les applis que j'écris moi-même. Mais c'est plus lourd et il y a beaucoup de bibliothèques qui utilisent les threads. A commencer par les serveurs HTTP. Et c'est justement pour faire du WEB que j'ai besoin de python.
Je joue avec les options de configuration pour l'instant.
Nicolas
Le 24/05/2013 09:03, Nicolas a écrit :
Bonjour,
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard (QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé sur un os. Voici un petit script de test :
A l'exécution, j'obtiens la sortie suivante : > python3 test.py test running... start thread Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ? Python n'est vraiment pas locace. En exécutant "python3 -vvvvvv test.py", c'est pas mieux ; j'ai juste "Memory fault" comme compte rendu.
S'il y a un expert dans la salle...
Nicolas
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
Le 24/05/2013 09:03, Nicolas a écrit :
Bonjour,
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard
(QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé sur
un os.
Voici un petit script de test :
A l'exécution, j'obtiens la sortie suivante :
> python3 test.py
test running...
start thread
Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ?
Python n'est vraiment pas locace.
En exécutant "python3 -vvvvvv test.py", c'est pas mieux ; j'ai juste
"Memory fault" comme compte rendu.
S'il y a un expert dans la salle...
Nicolas
J'ai identifié et contourné le problème.
Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet.
Sauf si quelqu'un est intéressé.
J'essaie de compiler cpython (3.2.2) pour une plateforme non standard (QNX Neutrino 6.5.0). Le travail est bien avancé mais je suis tombé sur un os. Voici un petit script de test :
A l'exécution, j'obtiens la sortie suivante : > python3 test.py test running... start thread Memory fault
Clairement, les threads posent problème. Mais comment debugger ça ? Python n'est vraiment pas locace. En exécutant "python3 -vvvvvv test.py", c'est pas mieux ; j'ai juste "Memory fault" comme compte rendu.
S'il y a un expert dans la salle...
Nicolas
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
Damien Wyart
* Nicolas in fr.comp.lang.python:
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Si ça ne te prend pas trop de temps, je veux bien un petit résumé.
Merci !
-- DW
* Nicolas <nicolasp@aaton.com> in fr.comp.lang.python:
J'ai identifié et contourné le problème. Un peu compliqué à expliquer
donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est
intéressé.
Si ça ne te prend pas trop de temps, je veux bien un petit résumé.
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Si ça ne te prend pas trop de temps, je veux bien un petit résumé.
Merci !
-- DW
Nicolas
Le 27/05/2013 10:43, Damien Wyart a écrit :
* Nicolas in fr.comp.lang.python:
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Si ça ne te prend pas trop de temps, je veux bien un petit résumé.
Merci !
J'essaie de compiler cpython pour un OS temps réel (QNX Neutrino 6.5.0) qui tourne sur une cible PowerPC ou ARM-V7. La cible (PPC ou ARM) implique une cross compilation, ce qui est déjà problématique pour cPython. Je me concentre pour l'instant sur ARM. Après avoir fait quelques tentatives moi même avec diverses versions et patches, je me suis apperçu que Blackberry a déjà fait le boulot. Blackberry délivre son OS avec cPython3.2.2. Or l'OS blackberry est très fortement basé sur QNX. J'ai trouvé la repository de BlackBerry (https://github.com/blackberry/Python) et modifié les options de compilation pour pouvoir compiler pour QNX 6.5.0. Après compilation, et installation sur la cible, je fais quelques tests et tombe sur le problème du "Memory fault". Le message ne vient en fait pas de Python mais de l'OS. En fait Python s'est crashé. Après investigation, il se trouve que BlackBerry a patché le module threading. C'est ce patch qui fait crasher Python lorsque l'on utilise un thread. Je l'ai supprimé et tout est rentré dans l'ordre. Cela ne veut pas dire que tout fonctionne bien car le patch en question ne devrait pas faire crasher Python. Le patch utilise ctypes pour charger une librairie et appeler une fonction du système (nommage du thread au niveau système). L'appel de la fonction système pose problème. Il doit donc y avoir un bug dans ctypes (problème d'option de compilation ?). Sauf que les tests de régression de ctypes se font sans erreur. D'autres tests de régression ne passent pas. Bref, y a encore du boulot.
Nicolas
Le 27/05/2013 10:43, Damien Wyart a écrit :
* Nicolas <nicolasp@aaton.com> in fr.comp.lang.python:
J'ai identifié et contourné le problème. Un peu compliqué à expliquer
donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est
intéressé.
Si ça ne te prend pas trop de temps, je veux bien un petit résumé.
Merci !
J'essaie de compiler cpython pour un OS temps réel (QNX Neutrino 6.5.0)
qui tourne sur une cible PowerPC ou ARM-V7. La cible (PPC ou ARM)
implique une cross compilation, ce qui est déjà problématique pour
cPython. Je me concentre pour l'instant sur ARM.
Après avoir fait quelques tentatives moi même avec diverses versions et
patches, je me suis apperçu que Blackberry a déjà fait le boulot.
Blackberry délivre son OS avec cPython3.2.2. Or l'OS blackberry est très
fortement basé sur QNX. J'ai trouvé la repository de BlackBerry
(https://github.com/blackberry/Python) et modifié les options de
compilation pour pouvoir compiler pour QNX 6.5.0.
Après compilation, et installation sur la cible, je fais quelques tests
et tombe sur le problème du "Memory fault".
Le message ne vient en fait pas de Python mais de l'OS. En fait Python
s'est crashé.
Après investigation, il se trouve que BlackBerry a patché le module
threading. C'est ce patch qui fait crasher Python lorsque l'on utilise
un thread. Je l'ai supprimé et tout est rentré dans l'ordre.
Cela ne veut pas dire que tout fonctionne bien car le patch en question
ne devrait pas faire crasher Python. Le patch utilise ctypes pour
charger une librairie et appeler une fonction du système (nommage du
thread au niveau système). L'appel de la fonction système pose problème.
Il doit donc y avoir un bug dans ctypes (problème d'option de
compilation ?). Sauf que les tests de régression de ctypes se font sans
erreur.
D'autres tests de régression ne passent pas.
Bref, y a encore du boulot.
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Si ça ne te prend pas trop de temps, je veux bien un petit résumé.
Merci !
J'essaie de compiler cpython pour un OS temps réel (QNX Neutrino 6.5.0) qui tourne sur une cible PowerPC ou ARM-V7. La cible (PPC ou ARM) implique une cross compilation, ce qui est déjà problématique pour cPython. Je me concentre pour l'instant sur ARM. Après avoir fait quelques tentatives moi même avec diverses versions et patches, je me suis apperçu que Blackberry a déjà fait le boulot. Blackberry délivre son OS avec cPython3.2.2. Or l'OS blackberry est très fortement basé sur QNX. J'ai trouvé la repository de BlackBerry (https://github.com/blackberry/Python) et modifié les options de compilation pour pouvoir compiler pour QNX 6.5.0. Après compilation, et installation sur la cible, je fais quelques tests et tombe sur le problème du "Memory fault". Le message ne vient en fait pas de Python mais de l'OS. En fait Python s'est crashé. Après investigation, il se trouve que BlackBerry a patché le module threading. C'est ce patch qui fait crasher Python lorsque l'on utilise un thread. Je l'ai supprimé et tout est rentré dans l'ordre. Cela ne veut pas dire que tout fonctionne bien car le patch en question ne devrait pas faire crasher Python. Le patch utilise ctypes pour charger une librairie et appeler une fonction du système (nommage du thread au niveau système). L'appel de la fonction système pose problème. Il doit donc y avoir un bug dans ctypes (problème d'option de compilation ?). Sauf que les tests de régression de ctypes se font sans erreur. D'autres tests de régression ne passent pas. Bref, y a encore du boulot.
Nicolas
BertrandB
Le 27/05/2013 10:07, Nicolas a écrit :
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross compilation pour un dsmg600 (PPC et uclibc). Malgré des tests ok en production je tobais sur des problèmes bizarre qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO le buffer récupérait des contenus de fichier incorrect. J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment fonctionnelle je suis évidement très intéressé.
Le 27/05/2013 10:07, Nicolas a écrit :
J'ai identifié et contourné le problème.
Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet.
Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross
compilation pour un dsmg600 (PPC et uclibc).
Malgré des tests ok en production je tobais sur des problèmes bizarre
qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO
le buffer récupérait des contenus de fichier incorrect.
J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment
fonctionnelle je suis évidement très intéressé.
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross compilation pour un dsmg600 (PPC et uclibc). Malgré des tests ok en production je tobais sur des problèmes bizarre qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO le buffer récupérait des contenus de fichier incorrect. J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment fonctionnelle je suis évidement très intéressé.
Nicolas
Le 30/05/2013 18:33, BertrandB a écrit :
Le 27/05/2013 10:07, Nicolas a écrit :
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross compilation pour un dsmg600 (PPC et uclibc). Malgré des tests ok en production je tobais sur des problèmes bizarre qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO le buffer récupérait des contenus de fichier incorrect. J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment fonctionnelle je suis évidement très intéressé.
Le PPC tourne sur quel OS ?
Le 30/05/2013 18:33, BertrandB a écrit :
Le 27/05/2013 10:07, Nicolas a écrit :
J'ai identifié et contourné le problème.
Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet.
Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross
compilation pour un dsmg600 (PPC et uclibc).
Malgré des tests ok en production je tobais sur des problèmes bizarre
qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO
le buffer récupérait des contenus de fichier incorrect.
J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment
fonctionnelle je suis évidement très intéressé.
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross compilation pour un dsmg600 (PPC et uclibc). Malgré des tests ok en production je tobais sur des problèmes bizarre qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO le buffer récupérait des contenus de fichier incorrect. J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment fonctionnelle je suis évidement très intéressé.
Le PPC tourne sur quel OS ?
BertrandB
Le 03/06/2013 08:47, Nicolas a écrit :
Le 30/05/2013 18:33, BertrandB a écrit :
Le 27/05/2013 10:07, Nicolas a écrit :
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross compilation pour un dsmg600 (PPC et uclibc). Malgré des tests ok en production je tobais sur des problèmes bizarre qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO le buffer récupérait des contenus de fichier incorrect. J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment fonctionnelle je suis évidement très intéressé.
Le PPC tourne sur quel OS ?
linux 2.4 ...http://dsmg600.info j'ai soupçonné un problème de compatibilité entre Cpython (2.5 à l'époque) et uclibc sur ppc.
Le 03/06/2013 08:47, Nicolas a écrit :
Le 30/05/2013 18:33, BertrandB a écrit :
Le 27/05/2013 10:07, Nicolas a écrit :
J'ai identifié et contourné le problème.
Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet.
Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross
compilation pour un dsmg600 (PPC et uclibc).
Malgré des tests ok en production je tobais sur des problèmes bizarre
qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO
le buffer récupérait des contenus de fichier incorrect.
J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment
fonctionnelle je suis évidement très intéressé.
Le PPC tourne sur quel OS ?
linux 2.4 ...http://dsmg600.info
j'ai soupçonné un problème de compatibilité entre Cpython (2.5 à
l'époque) et uclibc sur ppc.
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross compilation pour un dsmg600 (PPC et uclibc). Malgré des tests ok en production je tobais sur des problèmes bizarre qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO le buffer récupérait des contenus de fichier incorrect. J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment fonctionnelle je suis évidement très intéressé.
Le PPC tourne sur quel OS ?
linux 2.4 ...http://dsmg600.info j'ai soupçonné un problème de compatibilité entre Cpython (2.5 à l'époque) et uclibc sur ppc.
Nicolas
Le 04/06/2013 21:07, BertrandB a écrit :
Le 03/06/2013 08:47, Nicolas a écrit :
Le 30/05/2013 18:33, BertrandB a écrit :
Le 27/05/2013 10:07, Nicolas a écrit :
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross compilation pour un dsmg600 (PPC et uclibc). Malgré des tests ok en production je tobais sur des problèmes bizarre qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO le buffer récupérait des contenus de fichier incorrect. J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment fonctionnelle je suis évidement très intéressé.
Le PPC tourne sur quel OS ?
linux 2.4 ...http://dsmg600.info j'ai soupçonné un problème de compatibilité entre Cpython (2.5 à l'époque) et uclibc sur ppc.
uclibc peut effectivement poser problème.
Un lien très utile pour cross-compiler Python : http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html
Mon cas est spécial car la cible ne tourne pas sous linux. Bizarrement, sur power-pc, je n'ai pas le même comportement que sur arm. Ca a l'air de mieux se passer sur power-pc. Je n'ai pas encore fait tous les tests mais j'ai un serveur web qui tourne.
Le 04/06/2013 21:07, BertrandB a écrit :
Le 03/06/2013 08:47, Nicolas a écrit :
Le 30/05/2013 18:33, BertrandB a écrit :
Le 27/05/2013 10:07, Nicolas a écrit :
J'ai identifié et contourné le problème.
Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet.
Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross
compilation pour un dsmg600 (PPC et uclibc).
Malgré des tests ok en production je tobais sur des problèmes bizarre
qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO
le buffer récupérait des contenus de fichier incorrect.
J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment
fonctionnelle je suis évidement très intéressé.
Le PPC tourne sur quel OS ?
linux 2.4 ...http://dsmg600.info
j'ai soupçonné un problème de compatibilité entre Cpython (2.5 à
l'époque) et uclibc sur ppc.
uclibc peut effectivement poser problème.
Un lien très utile pour cross-compiler Python :
http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html
Mon cas est spécial car la cible ne tourne pas sous linux.
Bizarrement, sur power-pc, je n'ai pas le même comportement que sur arm.
Ca a l'air de mieux se passer sur power-pc. Je n'ai pas encore fait tous
les tests mais j'ai un serveur web qui tourne.
J'ai identifié et contourné le problème. Un peu compliqué à expliquer donc je me m'étendrai pas sur le sujet. Sauf si quelqu'un est intéressé.
Nicolas
J'ai buté échoué sur un problème de gestion mémoire lors de la cross compilation pour un dsmg600 (PPC et uclibc). Malgré des tests ok en production je tobais sur des problèmes bizarre qui se sont avérés être une mauvaise gestion mémoire. Sur des grosses IO le buffer récupérait des contenus de fichier incorrect. J'ai beaucoup cherché et rien trouvé de probant ....
donc si vous arrivez à faire une cross compilation vraiment fonctionnelle je suis évidement très intéressé.
Le PPC tourne sur quel OS ?
linux 2.4 ...http://dsmg600.info j'ai soupçonné un problème de compatibilité entre Cpython (2.5 à l'époque) et uclibc sur ppc.
uclibc peut effectivement poser problème.
Un lien très utile pour cross-compiler Python : http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html
Mon cas est spécial car la cible ne tourne pas sous linux. Bizarrement, sur power-pc, je n'ai pas le même comportement que sur arm. Ca a l'air de mieux se passer sur power-pc. Je n'ai pas encore fait tous les tests mais j'ai un serveur web qui tourne.
