I’m trying to compile my Python helloworld.c again. The former errors are gone
for reasons that are not clear - there’s been a few iterations of rumprun since
then, maybe something in there changed, maybe some other thing changed I’m not
sure. Ugh. I admit I’m somewhat mashing keys and hoping something works like a
monkey writing shakespeare. I don’t like working that way but I don’t fully
understand alot of things so trial and error helps me learn.
Anyway. Can I trouble you to have a quick look at this command line please and
see if there’s anything obviously wrong? It says "error adding symbols: Bad
value"
As I understand it this command line is telling rumprun-xen-cc to compile my
hw.c and also telling it where the Python headers and shared library is.
(venv3.4)ubuntu@contiki:~/pycy$ rumprun-xen-cc $CFLAGS
-I/usr/include/python3.4m -o hw.xen hw.c -L/usr/lib/x86_64-linux-gnu
-lpython3.4m -lutil -fPIC
/usr/bin/ld: errno: TLS reference in hw.xen mismatches non-TLS reference in
/home/ubuntu/rumprun/platform/xen/rump/lib/libc.a(errno.o)
/home/ubuntu/rumprun/platform/xen/rump/lib/libc.a: error adding symbols: Bad
value
collect2: error: ld returned 1 exit status
and the exact same command works if I use your simple.c application.
(venv3.4)ubuntu@contiki:~/pycy$ rumprun-xen-cc $CFLAGS
-I/usr/include/python3.4m -o simple.xen simple.c -L/usr/lib/x86_64-linux-gnu
-lpython3.4m -lutil -fPIC
(venv3.4)ubuntu@contiki:~/pycy$ ls
cython hw hw.c hwgcc hw.py hwxen simple_baked.xen simple.c simple.xen
(venv3.4)ubuntu@contiki:~/pycy$ rumpbake xen_pv simple_baked.xen simple.xen
!!!
!!! NOTE: rumpbake is experimental. syntax may change in the future
!!!
(venv3.4)ubuntu@contiki:~/pycy$
or if I use gcc it does not give any errors:
(venv3.4)ubuntu@contiki:~/pycy$ gcc $CFLAGS -I/usr/include/python3.4m -o hw.xen
hw.c -L/usr/lib/x86_64-linux-gnu -lpython3.4m -lutil -fPIC
You did previously say:
But it appears to be the only way I have found so far to get the Python headers-I/usr/include/anything for rumprun-xen-cc seems wrong. It *might* be
accidentally correct in some situations, but generally speaking it's wrong.
pyconfig.h looks like something generated by gnu autoconf, so
there should not be any big problems in generating it.