On 18/06/15 04:53, Andrew Stuart wrote:
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.
Errors disappearing without explanation is always worrisome. The
recently closed rumprun issue #28 is a prime example.
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
Would you believe that it works because it doesn't use anything from
/usr/include/python3.4m or libpython3.4m ?
Btw, generally speaking, don't compile with -fPIC. It's not useful for
rumprun, and generates larger and slower code.
You did previously say:
-I/usr/include/anything for rumprun-xen-cc seems wrong. It *might* be
accidentally correct in some situations, but generally speaking it's wrong.
But it appears to be the only way I have found so far to get the Python headers
and library included.
Apparently for some reason you didn't believe me. It's still wrong.
Just because it happens to be there and sort of looks approximately the
same as something you want still doesn't mean it's what should be used.
Do you expect random libs from Windows or OS X to work against Linux
programs? If not, don't expect the analogous case to work here either.
Your options are:
1) build the contents of /usr/include/pythonetc with the rumprun toolchain
2) use python built on NetBSD, it should work (?)
Obviously, I daresay, "1" is the direction that we'd like to go in,
boosted with a packaging system. Unfortunately, pioneers don't have
access to a readily chewed packaging system and will have to resort to
hard work. I don't know how much work building libpython and the
headers is, but only one way to find out. It depends mostly on how
against the grain the python build system is.
If the python build system proves to be too stupid to support easy
cross-compilation, cheating a bit by using a NetBSD VM might be a quick
path to early victory. In theory, you could even download a NetBSD
binary package for python, expect that the standard binary packages
don't seem to contain a static version of libpython (*), so I think
building it yourself is the only option.
*) I checked the NetBSD 7 amd64 python3.3 binary package
Summary: even if you don't plan on running the python interpreter in
rumprun, you still need to build python against rumprun to produce the
libs/headers required by cpython.
