Huston, we've got a problem
Mam problem. PLD też ma problem. Właściwie rzecz biorąc to problem jest jeden i ten sam. Otóż automatyka służąca do budowania pakietów na wszystkich builderach na raz jest napisana w pythonie i... przez to nie działa. Jeśli wewnątrz chroota skompiluję sobie programik używający -pthreads (jest to standardowy programik używany przez ./configure, do sprawdzania, czy w systemie jest wsparcie dla wątków; zwany dalej conftest) i odpalę go, to ślicznie zadziała. Jeśli z zewnątrz chroota zrobię 'sudo chroot ~/chroot /tmp/conftest' to też ślicznie zadziała. Jeśli natomiast z zewnątrz chroota odpalę skrypt pythonowy który będzie robił os.system("sudo chroot ~/chroot /tmp/conftest"), to ów conftest się ślicznie wypieprzy wpadając w pętlę przy wywołaniu mmapa. Dla ciekawskich podaję jak wywołanie tego mmapa wygląda:
mmap(NULL, 2147483647, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
Chyba dla każdego jest jasne, czemu to nie ma prawa działać. Pomijając odpalanie przez pythona w każdym innym przypadku drugi argument mmapa jest taki, jaki powinien i całość działa jak trzeba. Jestem zły. Naprawienie tego pewnie będzie graniczyło z cudem, gdyż na zewnątrz chroota jest PLD1.0, a wewnątrz coś, co ma się stać PLD2.0 (hgw kiedy, gdyż przez ten błąd prace są wstrzymane), więc żaden normalny deweloper pythona/glibca/whatever nie zechce ruszyć czterych liter i sprawdzić co jest nie tak. Jedyna nadzieja w znalezieniu workaroundu. Chociaż. Gdyby ten błąd był powtarzalny gdzie indziej... czy któryś z czytelników byłby tak miły i powtórzył taką operację na jakiejś innej dystrybucji? Albo wymyślił jakiś workaround pozwalający zniwelować zgubny wpływ pythona na środowisko (od razu mówię, że os.system("./ble.sh") nie zadziała). Help.
Brb. Właśnie do mnie dotarło, że nikt poza mną pewnie nie ma ppc. Będę musiał coś wymyślić :/
mmap(NULL, 2147483647, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
Chyba dla każdego jest jasne, czemu to nie ma prawa działać. Pomijając odpalanie przez pythona w każdym innym przypadku drugi argument mmapa jest taki, jaki powinien i całość działa jak trzeba. Jestem zły. Naprawienie tego pewnie będzie graniczyło z cudem, gdyż na zewnątrz chroota jest PLD1.0, a wewnątrz coś, co ma się stać PLD2.0 (hgw kiedy, gdyż przez ten błąd prace są wstrzymane), więc żaden normalny deweloper pythona/glibca/whatever nie zechce ruszyć czterych liter i sprawdzić co jest nie tak. Jedyna nadzieja w znalezieniu workaroundu. Chociaż. Gdyby ten błąd był powtarzalny gdzie indziej... czy któryś z czytelników byłby tak miły i powtórzył taką operację na jakiejś innej dystrybucji? Albo wymyślił jakiś workaround pozwalający zniwelować zgubny wpływ pythona na środowisko (od razu mówię, że os.system("./ble.sh") nie zadziała). Help.
Brb. Właśnie do mnie dotarło, że nikt poza mną pewnie nie ma ppc. Będę musiał coś wymyślić :/
13 IX 2003 o 19:27:31
ale i tak masz ladna dupcie. 8=)