Clement Cherlin wrote:
I still haven't gotten compilation to finish, but it's a lot further
along than when I started. Currently, it fails with a zillion "undefined
reference" errors on the command
g++ -s -g -shared "C:/Users/Clement/src/parrot/parrot/src/extend.o"
-o python_group.dll "lib-python_group.o" "pybuiltin.o" "pyclass.o"
"pyobject.o" "pyboolean.o" "pycomplex.o" "pydict.o" "pyexception.o"
"pyfloat.o" "pyfunc.o" "pyboundmeth.o" "pyboundcall.o" "pynci.o"
"pystaticmeth.o" "pygen.o" "pyint.o" "pylist.o" "pylong.o" "pymodule.o"
"pynone.o" "pytype.o" "pyslice.o" "pystring.o" "pytuple.o"
"pyproxytype.o" "pyproxyclass.o" "pyiter.o"
C:/Users/Clement/src/parrot/parrot/src/extend.o(.text+0x306): In
function `Parrot_PMC_get_cstring_intkey':
C:/Users/Clement/src/parrot/parrot/src/extend.c:256: undefined reference
to `string_to_cstring'
C:/Users/Clement/src/parrot/parrot/src/extend.o(.text+0x363): In
function `Parrot_PMC_get_cstring':
C:/Users/Clement/src/parrot/parrot/src/extend.c:276: undefined reference
to `string_to_cstring'
C:/Users/Clement/src/parrot/parrot/src/extend.o(.text+0x3c6): In
function `Parrot_PMC_get_cstringn':
C:/Users/Clement/src/parrot/parrot/src/extend.c:299: undefined reference
to `string_to_cstring'
....
I've been working on getting dynclasses working on Cygwin. I've made
some changes to build_tools/build_dynclasses.pl (or strictly speaking
the file from which it is generated), and can now build dynclasses.
My understand is that on Windows DLLs must be self-contained and cannot
have unreferenced symbols, and so I've linked against libparrot.so which
of course pulls in much of its code. I see this also being done in the
MSWin32 case...
However... now for the bit I don't understand. Globals are now going to
exist in both the executable and another copy in the dynamically loaded
library. How does this usually get resolved?
At the moment I get a segfault in get_new_pmc_header in pmc.c when it
tried to access the wrong copy of the global Parrot_base_vtable which
hasn't been initialised (the code path is that loadlibs loads foo.dll
which in its load callback it calls pmc_new which eventually gets to
this routine).
Do dynclasses work with Windows or MinGW, or is this something that's
going to be a general problem on Windows?
Cheers,
Nick
p.s. Leo: Like HP-UX, cygwin also seems to require execute permissions
on the libraries in runtime/parrot/dynext/ for them to be dlopened
