Develop Reference

python script converted to C code via Cython is throwing this error upon execution: undefined symbol: PyObject_SelfIter

I converted a Python script to C code via Cython, creating "test.c". I then compile with:
gcc -static test.c -I/home/me/Python-3.9.12/include/python3.9 -o test.exe -L/home/me/Python-3.9.12/lib -lpython3.9 -lpthread -lutil -lrt -lm -ldl
When I run "test.exe" I get this error:
Original error was: /home/me/NEWER/numpy/core/_multiarray_umath.cpython-39-x86_64-linux-gnu.so: undefined symbol: PyObject_SelfIter
What I don't understand is that the symbol PyObject_SelfIter is defined in libpython3.9.a which I link in as seen in the compilation line. Why doesn't this linking take care of the undefined symbol noted above? How can I get around this error?
2 notes:
I am linking statically because I want to run the resulting executable on an Android system
as a test, I tried compiling without the -static flag, and the executable still yields the same error
thanks for any tips.

PythonXY: Error when compiling C Extension on Windows: bad reloc address 0x0 in section `.data' collect2.exe: error: ld returned 1 exit status

I face a problem when compiling pyxrr (http://carichte.github.io/pyxrr/) on a Windows 7 machine (64bit) when using the latest Version of PythonXY with mingw32.
In the past the Compilation worked without problems on similar machines.
The following error output is given:
run setup.py build -c mingw32
running build
running build_py
running build_ext
building 'pyxrr.xrr' extension
C:\MinGW32-xy\bin\gcc.exe -mdll -O -Wall -IC:\Python27\lib\site-packages\numpy\c
ore\include -IC:\Python27\include -IC:\Python27\PC -c pyxrr/xrr.c -o build\temp.
win32-2.7\Release\pyxrr\xrr.o -fopenmp
In file included from C:\Python27\lib\site-packages\numpy\core\include/numpy/nda
rraytypes.h:1761:0,
from C:\Python27\lib\site-packages\numpy\core\include/numpy/nda
rrayobject.h:17,
from C:\Python27\lib\site-packages\numpy\core\include/numpy/arr
ayobject.h:4,
from pyxrr/xrr.c:26:
C:\Python27\lib\site-packages\numpy\core\include/numpy/npy_1_7_deprecated_api.h:
12:9: note: #pragma message: C:\Python27\lib\site-packages\numpy\core\include/nu
mpy/npy_1_7_deprecated_api.h(12) : Warning Msg: Using deprecated NumPy API, disa
ble it by #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
#pragma message(_WARN___LOC__"Using deprecated NumPy API, disable it by " \
^
writing build\temp.win32-2.7\Release\pyxrr\xrr.def
C:\MinGW32-xy\bin\gcc.exe -shared -s build\temp.win32-2.7\Release\pyxrr\xrr.o bu
ild\temp.win32-2.7\Release\pyxrr\xrr.def -LC:\Python27\libs -LC:\Python27\PCbuil
d -lpython27 -lmsvcr90 -o build\lib.win32-2.7\pyxrr\xrr.pyd -fopenmp
build\temp.win32-2.7\Release\pyxrr\xrr.o:xrr.c:(.text+0x188): undefined referenc
e to `cexp'
build\temp.win32-2.7\Release\pyxrr\xrr.o:xrr.c:(.text+0x32c): undefined referenc
e to `cexp'
build\temp.win32-2.7\Release\pyxrr\xrr.o:xrr.c:(.text+0x42c): undefined referenc
e to `cexp'
build\temp.win32-2.7\Release\pyxrr\xrr.o:xrr.c:(.text+0xb4a): undefined referenc
e to `cexp'
build\temp.win32-2.7\Release\pyxrr\xrr.o:xrr.c:(.text+0xccf): undefined referenc
e to `cexp'
build\temp.win32-2.7\Release\pyxrr\xrr.o:xrr.c:(.text+0xda5): more undefined ref
erences to `cexp' follow
build\temp.win32-2.7\Release\pyxrr\xrr.o:xrr.c:(.text+0x100e): undefined referen
ce to `csqrt'
build\temp.win32-2.7\Release\pyxrr\xrr.o:xrr.c:(.text+0x1898): undefined referen
ce to `csqrt'
c:/mingw32-xy/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: build
\temp.win32-2.7\Release\pyxrr\xrr.o: bad reloc address 0x0 in section `.data'
collect2.exe: error: ld returned 1 exit status
An exception has occurred, use %tb to see the full traceback.
SystemExit: error: command 'gcc' failed with exit status 1
The same error occures if I do not use the multi processing option and libraries (--single-core flag). I was searching the web and trying different compiler options like -lm, -DKM_WIN32 etc. without effect. But python as well as mingw run as 32bit versions.
Apparently he doesn't find complex.h library functions which are actually standard.
I tried this on 2 different Win7 machines. Also, compiling using Anaconda works for the single-threaded version.
Since I don't really understand the problems, I hope someone can tell me where it lies.
Any hint is appreciated,
Thank you!

clang: error: unknown argument: '-mno-fused-madd'

When installing ReportLab 3.1.8, I ran into the problem where I kept getting the error and I could not find where this compiler option was being set.
The point in setup was:
building 'reportlab.lib._rl_accel' extension
clang: error: unknown argument: '-mno-fused-madd' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
error: command 'cc' failed with exit status 1

Here is my solution.
Cause: I keep my mac up to date and as a result it seems I now have a newer (different) version of the c compiler (clang) than the one that allowed the "-mno-fused-madd" command line switch.
Solution: I did not find the above switch in any file in the reportlab source. It had to be on the computer itself. The culprit seemed to be in the distutils, because setup.py uses module distutils.
The problem was in the file /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_sysconfigdata.py. This file contains definitions as a dictionary named build_time_vars. We are obviously in the right place as we have a build time problem.
First make a copy as a safeguard.
sudo <editor> <file path> to edit the file.
Then editing this file, search for and remove the switch -mno-fused-madd from the file. I found it in line beginning with 'CFLAGS' since this is a compile flag.
Change the line:
... -fwrapv -mno-fused-madd -DENABLE_DTRACE ... to ... -fwrapv -DENABLE_DTRACE ...
Save the file and continue with your build. It will now stay fixed. No need for environment variables or any such thing.
Edit: While you are at it, remove both _sysconfigdata.pyc and _sysconfigdata.pyo files.

You can still repress these errors from clang by using the following environment variables:
export CFLAGS=-Qunused-arguments
export CPPFLAGS=-Qunused-arguments
A detailed answer to a similar question can be found here:
clang error: unknown argument: '-mno-fused-madd' (python package installation failure)
According to the following the issue has also been fixed in OS X 10.9.3:
clang: error: unknown argument: '-mno-fused-madd' [-Wunused-command-line-argument-hard-error-in-future]

cannot find -lgsl and -lgslcblas

I am trying to compile a software called MRtrix in windows. It uses a python build script, (I have uploaded it here: http://pastebin.com/XnufSz53)
when I run this script I get the error pasted bellow.
I guess that the GSL libraries are not being found and I need to add a -L pointing to the library but because the compilation is being done by the python script I do not really now how to do this. Currently GnuWin is installed at C:\GnuWin32\
Thank you in advance,
Jesse
============================================================
ERROR: [LD] lib\mrtrix-0_2_11.dll
g++ -shared lib\image\format\base.o lib\math\vector.o lib\file\mmap.o lib\args.o
lib\image\format\dicom.o lib\file\dicom\select_cmdline.o lib\file\key_value.o l
ib\image\axis.o lib\image\format\mrtrix.o lib\image\interp.o lib\data_type.o lib
\point.o lib\image\mapper.o lib\file\dicom\element.o lib\file\dicom\mapper.o lib
\file\dicom\patient.o lib\file\dicom\quick_scan.o lib\image\object.o lib\mrtrix.
o lib\image\format\xds.o lib\file\dicom\dict.o lib\app.o lib\math\matrix.o lib\f
ile\config.o lib\image\format\mri.o lib\file\dicom\image.o lib\math\linalg.o lib
\file\dicom\study.o lib\file\dicom\series.o lib\image\name_parser.o lib\image\fo
rmat\list.o lib\file\dicom\tree.o lib\image\fft.o lib\image\header.o lib\image\f
ormat\analyse.o lib\image\format\nifti1.o -LC:/gtkmm64/lib -lglibmm-2.4 -lgobjec
t-2.0 -lsigc-2.0 -lgthread-2.0 -lglib-2.0 -lintl -lgsl -lgslcblas -lz -o lib\mrt
rix-0_2_11.dll
failed with output:
c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: cannot fin
d -lgsl
c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: cannot fin
d -lgslcblas
collect2.exe: error: ld returned 1 exit status
============================================================

Building CPython using clang invokes /usr/bin/ld for final link, and gets "/usr/bin/ld: error: libpython3.2m.a: malformed archive header name at 8"

I'm attempting to build CPython 3.2 using llvm's clang. It builds OK with gcc. I'm on Linux Mint 12.
The compile seems to go fine until the end, where it attempts to produce the ./python binary. The error I get is:
clang -pthread -Xlinker -export-dynamic -o python Modules/python.o libpython3.2m.a -lpthread -ldl -lutil -lm
/usr/bin/ld: error: libpython3.2m.a: malformed archive header name at 8
./Modules/python.c:25: error: undefined reference to 'PyMem_Malloc'
./Modules/python.c:27: error: undefined reference to 'PyMem_Malloc'
./Modules/python.c:51: error: undefined reference to '_Py_char2wchar'
./Modules/python.c:59: error: undefined reference to 'Py_Main'
./Modules/python.c:61: error: undefined reference to 'PyMem_Free'
./Modules/python.c:63: error: undefined reference to 'PyMem_Free'
./Modules/python.c:64: error: undefined reference to 'PyMem_Free'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've tried with the llvm 2.9 that's in my trusty Linux Mint 12 .deb repo, and with an SVN trunk of llvm from earlier today, but both give the same errors.
It occurs to me that perhaps things would go better if I could persuade clang to use llvm-link instead of /usr/bin/ld for linking, but I see nothing in the documentation about how to do that. Just setting $LD to llvm-link doesn't appear to help.
Those undefined references are likely red herrings: If I nm -o libpython3.2m.a (or llvm-nm -o libpython3.2m.a - both work), I can see that at least one of these symbols really is defined (according to nm of course - other tools could perhaps, and likely do, have other ideas).
Ultimately I want to generate llvm bitcode rather than an ELF binary, but it'd be a satisfying mini-milestone to get a working python ELF binary with llvm first.
I'm currently using the following for compilation:
export PATH=/usr/local/llvm/bin:$PATH
prefix=/usr/local/p3ib-3.2
export CC='clang'
export AR='llvm-ar'
export LD='llvm-link -emit-llvm-bc'
export RANLIB='llvm-ranlib'
./configure --prefix="$prefix" && make -j 3
Thanks!