Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Win32 dynclasses build issues

10 views
Skip to first unread message

Jonathan Worthington

unread,
Dec 28, 2004, 7:41:12 PM12/28/04
to perl6-i...@perl.org
Hi,

Sorry for not being about for quite a while. Time to get Parrot building
fully on Win32 again. :-)

At the moment, the Parrot executable is building fine, but dynclasses bit
hits some problems. Some of them were down to various Win32-isms, e.g. \'s
and spaces featuring in paths. The attached patch addresses these. I've
tried not to do things that will break the build on any other OS, but I'd
recommend checking before applying.

The bit I'm not so sure about is the link problem. Here's what happens:-

--
link -nologo -dll -def:..\libparrot.def
../src/extend.obj -out:python_group.dll
lib-python_group.obj pybuiltin.obj pynci.obj pyclass.obj pyobject.obj
pyboolean.
obj pycomplex.obj pydict.obj pyexception.obj pyfloat.obj pyfunc.obj
pygen.obj py
int.obj pylist.obj pylong.obj pymodule.obj pynone.obj pytype.obj
pystaticmeth.ob
j pyslice.obj pystring.obj pytuple.obj pyproxytype.obj pyproxyclass.obj
pyiter.o
bj
libparrot.def : error LNK2001: unresolved external symbol
Parrot_DynOp_core_0_1_1
libparrot.def : error LNK2001: unresolved external symbol Parrot_debug
libparrot.def : error LNK2001: unresolved external symbol Parrot_destroy
libparrot.def : error LNK2001: unresolved external symbol Parrot_disassemble
libparrot.def : error LNK2001: unresolved external symbol Parrot_init
libparrot.def : error LNK2001: unresolved external symbol Parrot_loadbc
libparrot.def : error LNK2001: unresolved external symbol Parrot_new
libparrot.def : error LNK2001: unresolved external symbol Parrot_readbc
libparrot.def : error LNK2001: unresolved external symbol Parrot_runcode
libparrot.def : error LNK2001: unresolved external symbol Parrot_setflag
libparrot.def : error LNK2001: unresolved external symbol Parrot_setwarnings
python_group.lib : fatal error LNK1120: 11 unresolved externals
LINK : fatal error LNK1141: failure during build of exports file
partial link python_group.dll failed (29952)
NMAKE : fatal error U1077: 'c:\Perl\bin\perl.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'c:\Perl\bin\perl.exe' : return code '0x2'
Stop.
--

If I add:-

..\blib\lib\libparrot_s.lib

Into the link line, I get this:-

--
link -nologo -dll -def:..\libparrot.def
../src/extend.obj -out:python_group.dll
..\blib\lib\libparrot_s.lib lib-python_group.obj pybuiltin.obj pynci.obj
pyclass
.obj pyobject.obj pyboolean.obj pycomplex.obj pydict.obj pyexception.obj
pyfloat
.obj pyfunc.obj pygen.obj pyint.obj pylist.obj pylong.obj pymodule.obj
pynone.ob
j pytype.obj pystaticmeth.obj pyslice.obj pystring.obj pytuple.obj
pyproxytype.o
bj pyproxyclass.obj pyiter.obj
libparrot.def : error LNK2001: unresolved external symbol Parrot_setflag
python_group.lib : fatal error LNK1120: 1 unresolved externals
LINK : fatal error LNK1141: failure during build of exports file
partial link python_group.dll failed (29952)
NMAKE : fatal error U1077: 'c:\Perl\bin\perl.exe' : return code '0x2'
Stop.
--

I'm not sure if I should be putting that in the link line anyway, and I'm
not sure what I'd add to locate that missing symbol.

Ideas?

Thanks,

Jonathan

dynclasses_pl.diff

Nicholas Clark

unread,
Dec 29, 2004, 5:44:37 AM12/29/04
to Jonathan Worthington, perl6-i...@perl.org
On Wed, Dec 29, 2004 at 12:41:12AM -0000, Jonathan Worthington wrote:

> At the moment, the Parrot executable is building fine, but dynclasses bit
> hits some problems. Some of them were down to various Win32-isms, e.g. \'s
> and spaces featuring in paths. The attached patch addresses these. I've
> tried not to do things that will break the build on any other OS, but I'd
> recommend checking before applying.

Thanks, applied.
(Worked on FreeBSD and OS X)

> The bit I'm not so sure about is the link problem. Here's what happens:-

I don't have any ideas about this yet. Sorry.

Nicholas Clark

Leopold Toetsch

unread,
Dec 29, 2004, 5:48:50 AM12/29/04
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:

> Sorry for not being about for quite a while. Time to get Parrot building
> fully on Win32 again. :-)

Great, thanks.

> libparrot.def : error LNK2001: unresolved external symbol Parrot_setflag

Obsolete API - isn't existing anymore. Removed.

leo

Jonathan Worthington

unread,
Dec 29, 2004, 8:31:59 PM12/29/04
to l...@toetsch.at, perl6-i...@perl.org
"Leopold Toetsch" <l...@toetsch.at> wrote:

> Jonathan Worthington <jona...@jwcs.net> wrote:
>> libparrot.def : error LNK2001: unresolved external symbol Parrot_setflag
>
> Obsolete API - isn't existing anymore. Removed.
>
OK, with the attached patch (which feels kinda hacky, but works) the build
completes. That's the good news. The bad news is that almost all of the
dynclasses tests fail. Here's an example of what I'm seeing:-

--
# Failed test (t\dynclass\pyint.t at line 497)
t\dynclass\pyint....NOK 21# got: 'Illegal PMC enum (0) in new
# '
# expected: '-13 -13
# '
# '(cd . && .\parrot.exe -b --gc-debug "C:\Documents and
Settings\Jonathan.SERVE
R\Desktop\POW\parrot\t\dynclass\pyint_21.imc")' failed with exit code 1
t\dynclass\pyint....NOK 22# Failed test (t\dynclass\pyint.t at line 519)
# got: 'Illegal PMC enum (0) in new
# '
# expected: '3 3 3 3
# '
# '(cd . && .\parrot.exe -b --gc-debug "C:\Documents and
Settings\Jonathan.SERVE
R\Desktop\POW\parrot\t\dynclass\pyint_22.imc")' failed with exit code 1
# Failed test (t\dynclass\pyint.t at line 548)
# got: 'Illegal PMC enum (0) in new
# '
# expected: '44 44 44
# '
# '(cd . && .\parrot.exe -b --gc-debug "C:\Documents and
Settings\Jonathan.SERVE
R\Desktop\POW\parrot\t\dynclass\pyint_23.imc")' failed with exit code 1
--

Any ideas about what's wrong or suggestions for where I should start
digging? I know that the various DLLs built by the dynclasses makefile
finish up in runtime/parrot/dynext. Don't know if this means anything, but
all of the library tests pass, suggesting the problem isn't with Parrot
locating the libraries.

Thanks,

Jonathan

dynclasses_2.diff

Leopold Toetsch

unread,
Dec 30, 2004, 8:07:27 AM12/30/04
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:
>>
> OK, with the attached patch (which feels kinda hacky, but works) the build
> completes. That's the good news.

Thanks, applied.

> ... The bad news is that almost all of the
> dynclasses tests fail.

I assume that the dynamic python lib has to export public symbols. You
could run one of the failing tests with a debugger and check the
Parrot_load_lib() steps.

leo

Jonathan Worthington

unread,
Dec 30, 2004, 8:17:25 PM12/30/04
to l...@toetsch.at, perl6-i...@perl.org
OK, you were right. Once I inserted __declspec(dllexport) into the
declaration of Parrot_lib_python_group_load, Parrot_dlsym returned the
address of the function in the DLL and it was called. I'll fix up a patch
to get that inserted.

With that working, there's still a problem. Parrot would (silently) exit
and never get past the loadlib line in the IMC file. Tracing the problem, I
found that it occurred in get_new_pmc_header, called from pmc_new_noinit
from pmc_new from Parrot_lib_python_group_load, on the line:-

VTABLE *vtable = Parrot_base_vtables[base_type];

Because Parrot_base_vtables was null.

My python_group.dll is almost 2MB in size. I'm thinking that when it's
being linked, it is linking a separate copy of Parrot (from libparrot_s.lib,
which I added to the link line to make the build not complain about missing
symbols). That means different globals, which leads to the problem. Might
my analysis be correct, and any ideas on where to go from here?

Thanks,

Jonathan

Leopold Toetsch

unread,
Dec 31, 2004, 6:02:04 AM12/31/04
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:

> "Leopold Toetsch" <l...@toetsch.at> wrote:
>>
>> I assume that the dynamic python lib has to export public symbols. You
>> could run one of the failing tests with a debugger and check the
>> Parrot_load_lib() steps.
>>
> OK, you were right. Once I inserted __declspec(dllexport) into the
> declaration of Parrot_lib_python_group_load, Parrot_dlsym returned the
> address of the function in the DLL and it was called. I'll fix up a patch
> to get that inserted.

> VTABLE *vtable = Parrot_base_vtables[base_type];

> Because Parrot_base_vtables was null.

> My python_group.dll is almost 2MB in size. I'm thinking that when it's
> being linked, it is linking a separate copy of Parrot (from libparrot_s.lib,
> which I added to the link line to make the build not complain about missing
> symbols). That means different globals, which leads to the problem. Might
> my analysis be correct, and any ideas on where to go from here?

Yep, that's correct. I had that during my first experiments with
loadable classes in linux too. Studying linker flags up and down led to
the current link flag settings "-Wl,-E" for gcc. You have to convince
the linker that unknown symbols in the shared library have to be
resolved against libparrot dynamically, when the library is loaded,
instead of duplicating globals and pulling in functions from that
libparrot.

This may work with some linker flags, via the .def file or by some
__declspec() magic. You might have a look at perl5 source, albeit I
don't know, if shared libs are supported for Win32. Reading docs and/or
asking in a win programming newsgroup might help too.

> Jonathan

leo

0 new messages