python-numpy-1.4.1/_configtest.c:6: undefined reference to `exp' (Trac #1526)

[thouis]

Original ticket http://projects.scipy.org/numpy/ticket/1526 on 2010-06-29 by @sandrotosi, assigned to unknown.

Hello,
this bug has been filed in the Debian BTS as http://bugs.debian.org/527707 and I'm now forwarding it here.

The report above is about 1.2.1 but it still applies in 1.4.1:

compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/sr
c/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.6 -c'
gcc: _configtest.c
_configtest.c:1: warning: conflicting types for built-in function ‘exp’
gcc -pthread _configtest.o -o _configtest
_configtest.o: In function `main':
/home/morph/deb/build-area/python-numpy-1.4.1/_configtest.c:6: undefined reference to `exp'
collect2: ld returned 1 exit status
_configtest.o: In function `main':
/home/morph/deb/build-area/python-numpy-1.4.1/_configtest.c:6: undefined reference to `exp'
collect2: ld returned 1 exit status
failure.
removing: _configtest.c _configtest.o
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -g -Wall -O2 -fPIC

a complete log can be found here: http://people.debian.org/~morph/tmp/python-numpy_1.4.1-1_amd64.build.bz2

Thanks in advance for your help,
Sandro

[numpy-gitbot]

@rgommers wrote on 2010-07-03

This looks like a Debian packaging issue to me. 1.4.1 builds fine on amd64 AFAIK. The second comment on the linked bug report indicates this too.

The _configtest compiles are allowed to fail, unless it stops the build process this is not an issue.

Closing as invalid, if you want to reopen please attach a build log of a plain build of python setup.py install on amd64.

[numpy-gitbot]

@sandrotosi wrote on 2010-07-19

Replying to [comment:1 rgommers]:

This looks like a Debian packaging issue to me. 1.4.1 builds fine on amd64 AFAIK. The second comment on the linked bug report indicates this too.

Sorry if I didn't make that clear enough: yes, the build continues and completes correctly, only that seeing those errors could have been a "signal" for an imminent problem.

The _configtest compiles are allowed to fail, unless it stops the build process this is not an issue.

Could you please explain a bit more? for example: why they are supposed to fail? :)

Closing as invalid, if you want to reopen please attach a build log of a plain build of python setup.py install on amd64.

I've run python setup.py build on amd64 and the compilation goes until the end correctly, but (of course) still shows the above error.

Regards,
Sandro

[numpy-gitbot]

@rgommers wrote on 2010-07-20

The configtest are, as the name suggests, attempts to compile some simple C code with different sizes for built-in types, as I understand it. Maybe some other checks, not sure about that. In the end a configuration should be found that compiles without problems. So it's allowed to fail, but not to throw an error that stops the build process.

It is a Python distutils thing, look at Pythonx.y.z/Lib/distutils/command/config.py (helpfully undocumented).

[numpy-gitbot]

@cournape wrote on 2010-07-22

Replying to [comment:2 sandro.tosi]:

I've run python setup.py build on amd64 and the compilation goes until the end correctly, but (of course) still shows the above error.

The build error is expected, it is exactly as autoconf tests which sometimes fail. You could argue there is a bug because it should not show up, but output control in distutils is so dumb than fixing it without removing useful log information would take time,

cheers,

David

[numpy-gitbot]

@sandrotosi wrote on 2010-07-22

Replying to [comment:4 cdavid]:

Replying to [comment:2 sandro.tosi]:

I've run python setup.py build on amd64 and the compilation goes until the end correctly, but (of course) still shows the above error.

The build error is expected, it is exactly as autoconf tests which sometimes fail. You could argue there is a bug because it should not show up, but output control in distutils is so dumb than fixing it without removing useful log information would take time,

No problem, i'm perfectly fine with this reply (and so I have something to justify closing the Debian bug report :) ).

Cheers,
Sandro