New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"cannot run C compiled programs" error while installing gevent==1.0.2 #570

Closed
sachinpkale opened this Issue Jun 10, 2015 · 7 comments

Comments

Projects
None yet
4 participants
@sachinpkale

sachinpkale commented Jun 10, 2015

I am running pip install gevent==1.0.2 on centos and getting following error:

running build_ext
    configure: error: in `/tmp/pip-build-Z3r2L2/gevent/build/temp.linux-x86_64-2.7/libev':
    configure: error: cannot run C compiled programs.
    If you meant to cross compile, use `--host'.
    See `config.log' for more details
    Running '/bin/sh /tmp/pip-build-Z3r2L2/gevent/libev/configure > configure-output.txt' in /tmp/pip-build-Z3r2L2/gevent/build/temp.linux-x86_64-2.7/libev
    building 'gevent.core' extension
    creating build/temp.linux-x86_64-2.7/gevent
    gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DLIBEV_EMBED=1 -DEV_COMMON= -DEV_CLEANUP_ENABLE=0 -DEV_EMBED_ENABLE=0 -DEV_PERIODIC_ENABLE=0 -Ibuild/temp.linux-x86_64-2.7/libev -Ilibev -I/usr/local/include/python2.7 -c gevent/gevent.core.c -o build/temp.linux-x86_64-2.7/gevent/gevent.core.o
    In file included from gevent/libev.h:2,
                     from gevent/gevent.core.c:249:
    libev/ev.c:45:22: error: config.h: No such file or directory
    libev/ev.c:483:48: warning: "/*" within comment
    In file included from gevent/libev.h:2,
                     from gevent/gevent.core.c:249:
    libev/ev.c:1625: warning: 'ev_default_loop_ptr' initialized and declared 'extern'
    In file included from gevent/libev.h:2,
                     from gevent/gevent.core.c:249:
    libev/ev.c: In function 'ev_io_start':
    libev/ev.c:3648: warning: suggest parentheses around arithmetic in operand of '|'
    libev/ev.c:4889:27: warning: "/*" within comment
    libev/ev.c:4890:27: warning: "/*" within comment
    error: command 'gcc' failed with exit status 1
@sachinpkale

This comment has been minimized.

Show comment
Hide comment
@sachinpkale

sachinpkale Jun 10, 2015

Running cat /etc/centos-release gives following:
CentOS release 6.5 (Final)

sachinpkale commented Jun 10, 2015

Running cat /etc/centos-release gives following:
CentOS release 6.5 (Final)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 30, 2015

i assume you have an issue with gcc.

Got the same weeks ago after manual patches for danted on debian 8.
Try compiling a gcc Hello World from command line, you should see gcc in bad condition...

ghost commented Jun 30, 2015

i assume you have an issue with gcc.

Got the same weeks ago after manual patches for danted on debian 8.
Try compiling a gcc Hello World from command line, you should see gcc in bad condition...

@jamadden

This comment has been minimized.

Show comment
Hide comment
@jamadden

jamadden Jul 1, 2015

Member

Closing because this does look like a system configuration problem. If you continue to see it, you might find more help from the mailing list. If you find that it does seem specific to gevent, please do feel free to reopen this.

Member

jamadden commented Jul 1, 2015

Closing because this does look like a system configuration problem. If you continue to see it, you might find more help from the mailing list. If you find that it does seem specific to gevent, please do feel free to reopen this.

@jamadden jamadden closed this Jul 1, 2015

@mvaled

This comment has been minimized.

Show comment
Hide comment
@mvaled

mvaled Sep 18, 2015

@jamadden

I'm facing the same problem, but I think it's probably a valid bug (needed to be reopened). I'm in Ubuntu 14.04, and the problem only happens when trying to install gevent (1.0.1 or 1.0.2) with pip or easy_install. If I uncompress the tarball and execute python setup.py install it works flawlessly. So gcc works.

Installing with pip using making LIBEV_EMBED=0 also works (if you have libev-dev installed).

I changed the setup.py to save the configuration-output.txt (easy_install remove the entire temp directory after it's done, so nothing survives...). The configure output when installed with easy_install is:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... 

It seems to halt there and produce the error we see in the output of easy_install about cross compilation.

Runing python setup.py build from an uncompressed tarball produces a complete configure-output file is produced and the first lines read:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no

So no cross compilation. Why does build_ext seems to believe we're trying to cross-compile when using easy_install?

mvaled commented Sep 18, 2015

@jamadden

I'm facing the same problem, but I think it's probably a valid bug (needed to be reopened). I'm in Ubuntu 14.04, and the problem only happens when trying to install gevent (1.0.1 or 1.0.2) with pip or easy_install. If I uncompress the tarball and execute python setup.py install it works flawlessly. So gcc works.

Installing with pip using making LIBEV_EMBED=0 also works (if you have libev-dev installed).

I changed the setup.py to save the configuration-output.txt (easy_install remove the entire temp directory after it's done, so nothing survives...). The configure output when installed with easy_install is:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... 

It seems to halt there and produce the error we see in the output of easy_install about cross compilation.

Runing python setup.py build from an uncompressed tarball produces a complete configure-output file is produced and the first lines read:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no

So no cross compilation. Why does build_ext seems to believe we're trying to cross-compile when using easy_install?

@jamadden

This comment has been minimized.

Show comment
Hide comment
@jamadden

jamadden Sep 18, 2015

Member

@mvaled How is your temporary directory (usually /tmp) mounted? What filesystem with what options? A direct install working, but pip failing, is commonly seen if /tmp doesn't support executable files (e.g., mounted +noexec). The solution is to fix /tmp or set $TMPDIR/$TEMPDIR to some other place. (A direct install compiles in place, pip puts everything into /tmp first. Games with symlinks around $TMPDIR can also cause this problem.)

Member

jamadden commented Sep 18, 2015

@mvaled How is your temporary directory (usually /tmp) mounted? What filesystem with what options? A direct install working, but pip failing, is commonly seen if /tmp doesn't support executable files (e.g., mounted +noexec). The solution is to fix /tmp or set $TMPDIR/$TEMPDIR to some other place. (A direct install compiles in place, pip puts everything into /tmp first. Games with symlinks around $TMPDIR can also cause this problem.)

@jamadden jamadden added the invalid label Sep 18, 2015

@mvaled

This comment has been minimized.

Show comment
Hide comment
@mvaled

mvaled Sep 18, 2015

You got it! It's a tmpfs with noexec. Thanks!

mvaled commented Sep 18, 2015

You got it! It's a tmpfs with noexec. Thanks!

@sys0dm1n

This comment has been minimized.

Show comment
Hide comment
@sys0dm1n

sys0dm1n Dec 4, 2015

Thank you @jamadden my /tmp was mounted with noexec

sys0dm1n commented Dec 4, 2015

Thank you @jamadden my /tmp was mounted with noexec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment