Bienvenue sur IndexError.

Ici vous pouvez poser des questions sur Python et le Framework Django.

Mais aussi sur les technos front comme React, Angular, Typescript et Javascript en général.

Consultez la FAQ pour améliorer vos chances d'avoir des réponses à vos questions.

Installer mysql-python [debian 7 - erreur gcc]

+3 votes

J'ai eu un gros problème aujourd'hui, j'ai un serveur qui tournait sur debian 7 avec python 2.7.3 et les virtualenvs qui fonctionnaient parfaitement. Puis Java a été installé dessus et a mis à jour la version de python en 2.7.10 et ça a tué tous mes virtualenvs bien sûr.

J'ai donc ré-installé mes requirements mais pas moyen d'arriver à installer mysql-python (v 1.2.5) qui s'installait sans soucis sur la version 2.7.3.

J'ai la traceback suivante quand je l'installe :

(labs) $ pip install mysql-python
Downloading/unpacking mysql-python
  Downloading MySQL-python-1.2.5.zip (108kB): 108kB downloaded
  Running setup.py (path:/home/user/dev/python/virtualenvs/labs/build/mysql-python/setup.py) egg_info for package mysql-python

Installing collected packages: mysql-python
  Running setup.py install for mysql-python
    building '_mysql' extension
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Dversion_info=(1,2,5,'final',1) -D__version__=1.2.5 -I/usr/include/mysql -I/usr/include/python2.7 -c _mysql.c -o build/temp.linux-x86_64-2.7/_mysql.o -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG
    x86_64-linux-gnu-gcc: error: unrecognized command line option '-fstack-protector-strong'
    error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
    Complete output from command /home/user/dev/python/virtualenvs/labs/bin/python -c "import setuptools, tokenize;__file__='/home/user/dev/python/virtualenvs/labs/build/mysql-python/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-9Mr_bO-record/install-record.txt --single-version-externally-managed --compile --install-headers /home/user/dev/python/virtualenvs/labs/include/site/python2.7:
    running install

running build

running build_py

creating build

creating build/lib.linux-x86_64-2.7

copying _mysql_exceptions.py -> build/lib.linux-x86_64-2.7

creating build/lib.linux-x86_64-2.7/MySQLdb

copying MySQLdb/__init__.py -> build/lib.linux-x86_64-2.7/MySQLdb

copying MySQLdb/converters.py -> build/lib.linux-x86_64-2.7/MySQLdb

copying MySQLdb/connections.py -> build/lib.linux-x86_64-2.7/MySQLdb

copying MySQLdb/cursors.py -> build/lib.linux-x86_64-2.7/MySQLdb

copying MySQLdb/release.py -> build/lib.linux-x86_64-2.7/MySQLdb

copying MySQLdb/times.py -> build/lib.linux-x86_64-2.7/MySQLdb

creating build/lib.linux-x86_64-2.7/MySQLdb/constants

copying MySQLdb/constants/__init__.py -> build/lib.linux-x86_64-2.7/MySQLdb/constants

copying MySQLdb/constants/CR.py -> build/lib.linux-x86_64-2.7/MySQLdb/constants

copying MySQLdb/constants/FIELD_TYPE.py -> build/lib.linux-x86_64-2.7/MySQLdb/constants

copying MySQLdb/constants/ER.py -> build/lib.linux-x86_64-2.7/MySQLdb/constants

copying MySQLdb/constants/FLAG.py -> build/lib.linux-x86_64-2.7/MySQLdb/constants

copying MySQLdb/constants/REFRESH.py -> build/lib.linux-x86_64-2.7/MySQLdb/constants

copying MySQLdb/constants/CLIENT.py -> build/lib.linux-x86_64-2.7/MySQLdb/constants

running build_ext

building '_mysql' extension

creating build/temp.linux-x86_64-2.7

x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Dversion_info=(1,2,5,'final',1) -D__version__=1.2.5 -I/usr/include/mysql -I/usr/include/python2.7 -c _mysql.c -o build/temp.linux-x86_64-2.7/_mysql.o -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG

x86_64-linux-gnu-gcc: error: unrecognized command line option '-fstack-protector-strong'

error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

----------------------------------------
Cleaning up...
Command /home/user/dev/python/virtualenvs/labs/bin/python -c "import setuptools, tokenize;__file__='/home/user/dev/python/virtualenvs/labs/build/mysql-python/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-9Mr_bO-record/install-record.txt --single-version-externally-managed --compile --install-headers /home/user/dev/python/virtualenvs/labs/include/site/python2.7 failed with error code 1 in /home/user/dev/python/virtualenvs/labs/build/mysql-python
Storing debug log for failure in /home/user/.pip/pip.log

J'ai un peu tout essayé, je suis tombé sur plein de thread sur SO qui disent d'install les lib de python-dev, de libmysqlclient-dev. J'ai vraiment tout installé ou dé-installé. Pour résoudre le problème j'ai monté un autre serveur sans installer Java. Mais ça m'ennuie de ne pas savoir pourquoi ça foire, surtout sur une lib assez critique comme ça.

En revanche comme python 3.4 n'a pas été touché sur le serveur faire un pip install libmysqlclient sur python34 ça ne pose pas de problème.

Honnêtement ce que je me suis dit c'est que l'install de Java a update gcc et du coup gcc n'arrive plus à installer.

demandé 1-Jun-2015 par Hawke (466 points)
edité 1-Jun-2015 par Hawke

1 Réponse

+4 votes
 
Meilleure réponse

a mis à jour la version de python en 2.7.10 et ça a tué tous mes virtualenvs bien sûr.

Dur, j'aurais pensé qu'un venv aurait survécu a ce genre de chose. Ils ne sont pas si isolés du système que ça.

Ça a l'air d’être lié a la version de GCC dispo sur ta machine vs la version de GCC avec laquelle il a été compilé. (voire ce commentaire)

Apparemment 2 solutions : mettre a jour GCC ou aller s'amuser avec la conf (cf commentaire SO)

répondu 1-Jun-2015 par jc (2,704 points)
sélectionné 1-Jun-2015 par Hawke

Edit : my bad j'avais pas symlink le bon gcc. Et ça marche du coup !

Merci bien !

Cool :)
Quelle solution du coup ?

J'ai mis à jour gcc.

Note pour ceux qui auraient le problème : après la mise à jour il faut changer le lien symbolique de /usr/bin/gcc et de /usr/bin/x86_64-linux-gnu-gcc.

Sous arch, pacman gère ça tout seul =D, à savoir la gestion des liens symboliques en fonction des installations

Tu geres des serveur de prod sous Arch ?
ça me parait a la limite de la roulette russe a chaque pacman -Suy.

pas de jugement hein :)
c'est juste que par rapport a une Debian, Ubuntu, CentOS ou autre, Arch c'est celle qui risque le plus de tout casser a chaque mise a jour ;)

C'est ce qui rend ça fun ;) (en plus arch donne la possibilité d'avoir plusieurs versions de noyaux installées à la fois, donc si un pète les autres sont toujours en vie)

T'es arguments sont surprenants (au bas mot)

Non, vraiment, si un jour tu dois gérer un serveur de prod, évite Arch.

Je plussoie @jc, je ne vais pas jouer à la roulette russe en prod ! (quoique... =D).

C'est bien parce que je ne gère rien pour le moment que je peux me permettre de tout casser sans aucune conséquence ;)

ps : on fait du h-s là non?

...