Error in configure for python

[Ben Fritz]

I'm trying to compile Vim as a normal user, with python support, on a Solaris machine at work. I have NO sudo access, and am trying to use a python I built myself (the Python version on the server is 2.2, and IT will NOT change it).

Here is the configure command I used:

./configure --with-features=huge --enable-pythoninterp --with-python-config-dir=/rfs/proj/cs_ifis_projects/Tools/Python/current/lib/python2.7/config > config.log

Everything seems to go OK at first, it finds Python alright anyway, but then disables python anyway:

checking --enable-pythoninterp argument... yes
checking for python2... /rfs/proj/cs_ifis_projects/Tools/Python/current/bin/python2
checking Python version... 2.7
checking Python is 1.4 or better... yep
checking Python's install prefix... /rfs/proj/cs_ifis_projects/Tools/Python/current
checking Python's execution prefix... /rfs/proj/cs_ifis_projects/Tools/Python/current
checking Python's configuration directory... (cached) /rfs/proj/cs_ifis_projects/Tools/Python/current/lib/python2.7/config
checking if -pthread should be used... yes
checking if compile and link flags for Python are sane... no: PYTHON DISABLED

Any hints on how to get this working?

[Ben Fritz]

I found this stackoverflow post: http://stackoverflow.com/questions/3373914/compiling-vim-with-python-support

Which led me to look at src/auto/config.log

Here I see something suspicious:

configure:5416: checking if -pthread should be used
configure:5443: gcc -o conftest -g -O2 -pthread -L/usr/local/lib conftest.c >&5
gcc: unrecognized option `-pthread'
configure:5443: $? = 0
configure:5444: result: yes
configure:5459: checking if compile and link flags for Python are sane
configure:5476: gcc -o conftest -g -O2 -I/rfs/proj/cs_ifis_projects/Tools/Python/current/include/python2.7 -DPYTHON_HOME=\"/rfs/proj/cs_ifis_projects/Tools/Python/current\" -pthread -L/usr/local/lib conftest.c -L/rfs/proj/cs_ifis_projects/Tools/Python/current/lib/python2.7/config -lpython2.7 -lresolv -lsocket -lnsl -lrt -ldl -lpthread -lm >&5
gcc: unrecognized option `-pthread'

It looks like configure checks that -pthread is supported, gets pretty convincing evidence that it is NOT supported (unrecognized option!) and then tries to use it anyway!

I tried manually editing src/auto/configure to remove the ability for the -pthread check to succeed, now it gets past the pthread part but still fails at the "compile and link flags are sane" step:

configure:5416: checking if -pthread should be used
configure:5448: result: no
configure:5452: checking if compile and link flags for Python are sane
configure:5469: gcc -o conftest -g -O2 -I/rfs/proj/cs_ifis_projects/Tools/Python/current/include/python2.7 -DPYTHON_HOME=\"/rfs/proj/cs_ifis_projects/Tools/Python/current\" -L/usr/local/lib conftest.c -L/rfs/proj/cs_ifis_projects/Tools/Python/current/lib/python2.7/config -lpython2.7 -lresolv -lsocket -lnsl -lrt -ldl -lpthread -lm >&5
conftest.c:0: unterminated string or character constant
conftest.c:0: possible real start of unterminated constant
configure:5469: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define UNIX 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_WAIT_H 1
| #define FEAT_HUGE 1
| #define USE_XSMP_INTERACT 1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:5473: result: no: PYTHON DISABLED

Now I'm even more lost than before.

The same stackoverflow thread contains a hint to modify a vi_cv_path_python_plibs variable, but I'm at a loss as to how to modify it or what it does.

[Andrei Olsen]

On Wednesday, June 5, 2013 11:47:43 PM UTC+2, Ben Fritz wrote:
> I found this stackoverflow post: http://stackoverflow.com/questions/3373914/compiling-vim-with-python-support
>
> Which led me to look at src/auto/config.log
>
> Here I see something suspicious:
>
> configure:5416: checking if -pthread should be used
> configure:5443: gcc -o conftest -g -O2 -pthread -L/usr/local/lib conftest.c >&5
> gcc: unrecognized option `-pthread'
> configure:5443: $? = 0
> configure:5444: result: yes
> configure:5459: checking if compile and link flags for Python are sane
> configure:5476: gcc -o conftest -g -O2 -I/rfs/proj/cs_ifis_projects/Tools/Python/current/include/python2.7 -DPYTHON_HOME=\"/rfs/proj/cs_ifis_projects/Tools/Python/current\" -pthread -L/usr/local/lib conftest.c -L/rfs/proj/cs_ifis_projects/Tools/Python/current/lib/python2.7/config -lpython2.7 -lresolv -lsocket -lnsl -lrt -ldl -lpthread -lm >&5
> gcc: unrecognized option `-pthread'
>
> It looks like configure checks that -pthread is supported, gets pretty convincing evidence that it is NOT supported (unrecognized option!) and then tries to use it anyway!

Which GCC version are you using?

[Ben Fritz]

Hard to say, really. "gcc --version" just says "2.95.2". Is that enough? I can compile Vim fine WITHOUT python support, and python itself seemed to compile fine.

[Ben Fritz]

On Wednesday, June 5, 2013 4:47:43 PM UTC-5, Ben Fritz wrote:
> configure:5452: checking if compile and link flags for Python are sane
> configure:5469: gcc -o conftest -g -O2 -I/rfs/proj/cs_ifis_projects/Tools/Python/current/include/python2.7 -DPYTHON_HOME=\"/rfs/proj/cs_ifis_projects/Tools/Python/current\" -L/usr/local/lib conftest.c -L/rfs/proj/cs_ifis_projects/Tools/Python/current/lib/python2.7/config -lpython2.7 -lresolv -lsocket -lnsl -lrt -ldl -lpthread -lm >&5
> conftest.c:0: unterminated string or character constant
> conftest.c:0: possible real start of unterminated constant
> configure:5469: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define UNIX 1
> | #define STDC_HEADERS 1
> | #define HAVE_SYS_WAIT_H 1
> | #define FEAT_HUGE 1
> | #define USE_XSMP_INTERACT 1
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> |
> | ;
> | return 0;
> | }

The configure script is compiling a simple program, which should never fail to compile, and checking to see if it links.

But somehow it is getting compile errors instead.

I copied the file content shown above into a test file, and ran the same gcc command, and it compiled fine.

So, I manually edited the configure file again, to remove the compile step and make that test always succeed. Now my Vim compiles and --version shows +python. :echo has('python') returns 1 and :python print 'hello' works.

There has to be a better way to make this succeed!

[Andrei Olsen]

Right... you need to use -pthreads (note the s) and not -pthread

[Ben Fritz]

Thanks for that, it allowed me to get that check working for my system specifically.

But the actual fix would check both -pthread AND -pthreads and would NOT decide to use it anyway if it failed.

And, it still gets a compile error when checking for "sane" libraries unless I remove that check.

I attached the diff I used to get it working, but this isn't a good fix because it removes some checks that are probably needed.

[Bram Moolenaar]

Ben Fritz wrote:

> On Wednesday, June 5, 2013 5:43:40 PM UTC-5, Andrei Olsen wrote:
> > On Thursday, June 6, 2013 12:32:41 AM UTC+2, Ben Fritz wrote:
> > > On Wednesday, June 5, 2013 5:27:27 PM UTC-5, Andrei Olsen wrote:
> > > > On Wednesday, June 5, 2013 11:47:43 PM UTC+2, Ben Fritz wrote:
> > > > > gcc: unrecognized option `-pthread'
> > > > >
> > > > > It looks like configure checks that -pthread is supported,
> > > > > gets pretty convincing evidence that it is NOT supported
> > > > > (unrecognized option!) and then tries to use it anyway!

Apparently gcc only prints this message but does not exit with an error
code. It would require changing the configure check to parse the output
from gcc when it succeeds.

I prefer that someone who can actually test it implements this.


--
The primary purpose of the DATA statement is to give names to constants;
instead of referring to pi as 3.141592653589793 at every appearance, the
variable PI can be given that value with a DATA statement and used instead
of the longer form of the constant. This also simplifies modifying the
program, should the value of pi change.
-- FORTRAN manual for Xerox Computers

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Andrei Olsen]

Ben, could you check this patch on your system? I threw in Solaris into VirtualBox, but check if flags are "sane" doesn't fail here.

[Ben Fritz]

Your patch takes care of the pthreads check, thanks!

But the "sane" check still fails. I got a hint from here:

http://mail.python.org/pipermail/distutils-sig/2002-January/002744.html

The problem is in the escaping of the -DPYTHON_HOME flag. I had to REMOVE the extra \ as in the attached diff.

Note, if I run the same gcc command used by the script for the "sane" check, on the same file, I get no errors when I leave in the extra \. Maybe that's a difference between my shell (currently tcsh, please don't ask) and the shell executing the configure script.

I'm sure that extra \ is there for a reason...so probably this is only a good solution on MY system. What systems need the extra escaping? Can we detect this before trying it?

[Ben Fritz]

On Tuesday, June 11, 2013 11:43:30 AM UTC-5, Ben Fritz wrote:
>
> But the "sane" check still fails. I got a hint from here:
>
> http://mail.python.org/pipermail/distutils-sig/2002-January/002744.html
>
> The problem is in the escaping of the -DPYTHON_HOME flag. I had to REMOVE the extra \ as in the attached diff.
>

The diff I attached before allows "configure" to succeed but then the build fails.

The new diff attached fixes both, using '' to surround the " in addition to removing the backslash.

[Bram Moolenaar]

Thanks. It works on my system as well. We also need it for Python 3.


--
hundred-and-one symptoms of being an internet addict:
149. You find your computer sexier than your girlfriend