dynclasses on Windows

0 views
Skip to first unread message

Nick Glencross

unread,
Jul 22, 2005, 11:51:02 AM7/22/05
to perl6-i...@perl.org
Guys,

I've been giving some thought to what needs doing to get dynclasses
working on Windows. I'm not particularly intimate with Windows, but use
cygwin quite a bit.

One area that I'm still not 100% clear about is the visibility of
symbols within DLLs and executables, so please be kind!

From previous posts, you may have seen a kludgey solution to getting
dynclasses working on cygwin. The basic scheme is:

* Build a libparrot.dll, which includes an appropriate *_config.o

* Build dynclasses which link against libparrot.dll

* Build parrot.exe against libparrot.dll

[My understanding is that] DLLs cannot have unresolved symbols, or at
least they must be linked against another DLL which can provide them.

Hence, dynclasses need to be linked against libparrot.dll at compile
time, and *_config.o files need to reside in the DLL.

What we do currently linking with the parrot executable against
*_config.o files isn't satisfactory on Windows.

Does that seem reasonable so far?


Now to the bit which causes problems. Because libparrot.dll is tightly
bound to the configuration (e.g. parrot_config.o) you might potentially
need three DLLs (for miniparrot, parrot and installed parrot), which is
horrible.

What I'd like like to propose is that the information in parrot_config.o
and install_config.o be selected by the caller, either through a (DLL)
global or an argument to parrot_get_config_string. That way,
libparrot.dll can be built against it, and its personally determined by
the harness (which is compiled with -DINSTALL or such-like).

To summarise, one recipe might be:

* Build libminiparrot.dll, which includes null_config.o

* Build miniparrot, linking against libminiparrot.dll

* Create parrot_config.o and install_config.o using miniparrot

* Build libparrot.dll with parrot_config.o and install_config.o

* Build parrot, linking against libparrot.dll

* Build dynclasses, linking against libparrot.dll

* Subsequently build installed_parrot, but get it to select the
install config

There are obviously variants upon this theme, particularly where naming
is concerned, but what I wanted to get across is what links against
what, and what to do about the *_config.o files. Obviously miniparrot
could be build using an archive library etc.


Be kind on me if I've misunderstood Windows-land!

Cheers,

Nick

Jonathan Worthington

unread,
Jul 23, 2005, 8:23:15 PM7/23/05
to ni...@glencros.demon.co.uk, perl6-i...@perl.org
"Nick Glencross" <ni...@glencros.demon.co.uk> wrote:
> I've been giving some thought to what needs doing to get dynclasses
> working on Windows. I'm not particularly intimate with Windows, but use
> cygwin quite a bit.
>
I've also been looking at this, but for native Win32 rather than cygwin. I
think they will be two slightly different cases, though I'm not that
familiar with cygwin. So between us, we may be able to make it work on
both. :-)

> One area that I'm still not 100% clear about is the visibility of
> symbols within DLLs and executables, so please be kind!

> ...


> [My understanding is that] DLLs cannot have unresolved symbols, or at
> least they must be linked against another DLL which can provide them.
>

As far as I can tell, the way it works on platforms that it does work on is
that the "DLLs" call into functions in the parrot executable. So you kinda
need to link against the parrot executable, or make sure your DLL refers to
functions in the Parrot executable.

I played around with this idea today and managed to get it working for a
simple test program. Please see here:-
http://www.jwcs.net/users/jonathan/cgi-bin/blog_read.pl?id=221

I'm pretty sure that by applying the same idea to Parrot I can get
dynclasses working with MS VC++ with not too much effort.

The basic issue is, we need to identify every function that we wish to
export from the Parrot executable that a dynpmc could call, and put their
names in a parrot.def file. We don't have a -E (--export-dynamic) option
like GCC (but doesn't cygwin use GNU ld too and thus have these flags too?).

I could use a few hints here from folks who know more about what to export
and building such a list. I'm thinking that we have some functions within
the Parrot core that we can just hardcode into a list becasue they won't
change too often, and then we automatically pull in functions from all the
headers that relate to built-in PMCs.

That said, I do like the idea (as shown by Nick) of building most of
parrot.exe's stuff into a DLL, though don't know if it's required. I'm not
sure I really understand where parrot_config.obj comes into all of this,
though, so I'm very likely missing something on the cygwin front.

Input welcome,

Jonathan

Nick Glencross

unread,
Jul 24, 2005, 4:55:35 PM7/24/05
to Jonathan Worthington, Perl 6 Internals
Jonathan Worthington wrote:

> "Nick Glencross" <ni...@glencros.demon.co.uk> wrote:
>
>> I've been giving some thought to what needs doing to get dynclasses
>> working on Windows. I'm not particularly intimate with Windows, but use
>> cygwin quite a bit.
>>
> I've also been looking at this, but for native Win32 rather than
> cygwin. I think they will be two slightly different cases, though I'm
> not that familiar with cygwin. So between us, we may be able to make
> it work on both. :-)
>
>> One area that I'm still not 100% clear about is the visibility of
>> symbols within DLLs and executables, so please be kind!
>> ...
>> [My understanding is that] DLLs cannot have unresolved symbols, or at
>> least they must be linked against another DLL which can provide them.
>>
> As far as I can tell, the way it works on platforms that it does work
> on is that the "DLLs" call into functions in the parrot executable.
> So you kinda need to link against the parrot executable, or make sure
> your DLL refers to functions in the Parrot executable.


I didn't know that DLLs could be linked against an executable... that
almost sounds too simple! I'll see if cygwin allows that when I get time
towards the end of the week,

Cheers,

Nick

Reply all
Reply to author
Forward
0 new messages