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

NCI Broken On Win32

14 views
Skip to first unread message

Jonathan Worthington

unread,
Oct 28, 2003, 12:23:44 PM10/28/03
to perl6-i...@perl.org
Hi,

The following used to work (back at the start of the month):-

loadlib P1, "user32.dll"

Now it results in the following error:-

Couldn't load 'runtime/parrot/dynext/user32.dll.so': unknow reason

Obviously, it certainly shouldn't append .so on the end, and it surely won't
find user32.dll in the parrot runtime folder. ;-)

Thanks,

Jonathan


Leopold Toetsch

unread,
Oct 28, 2003, 12:51:56 PM10/28/03
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:
> Hi,

> loadlib P1, "user32.dll"

There are 2 errors in that, one is mine :)
- I didn't use the configure define of PARROT_DLL_EXTENSION
- Your's is: don't append ".dll" - parrot does it

BTW - are the nci tests succeeding on Win32:

$ make libnci.dll
$ perl t/harness t/pmc/nci.t

> Thanks,

> Jonathan

leo

Jonathan Worthington

unread,
Oct 28, 2003, 1:33:36 PM10/28/03
to l...@toetsch.at, perl6-i...@perl.org
> > loadlib P1, "user32.dll"
>
> There are 2 errors in that, one is mine :)
> - I didn't use the configure define of PARROT_DLL_EXTENSION
> - Your's is: don't append ".dll" - parrot does it
Ah, that's changed, 'cus it used to work with me doing that. :-) So now it
loads the library, but fails here:-

dlfunc P0, P1, "MessageBoxA", "llttl"

With:-

Parrot VM: PANIC: Unknown signature type!
C file c:\documents and settings\jonathan\desktop\pow\parrot\src\nci.c, line
2532
Parrot file (unknown file), line 0

Again, this had all used to work fine.

> BTW - are the nci tests succeeding on Win32:
>
> $ make libnci.dll

That fails with:-

> nmake libnci.dll

Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

NMAKE : fatal error U1073: don't know how to make 'parrot'
Stop.

The lines in my makefile are:-

libnci$(SO): $(SRC)\nci_test.c parrot$(EXE)
$(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS) $< -o $@

> $ perl t/harness t/pmc/nci.t
All tests skipped, 'cus of the above problem.

--

BTW, I sent in a couple of patches (that got rid of a lot of the Win32
warnings). Do you know what came of them? The warnings they fixed seem to
be gone in the latest CVS checkout, but nobody mentioned if they were
applied, or rejected and proper fixes done. Just curious to know. I don't
mind my patches being rejected, but if I submit a bad patch it's helpful if
I can know why it's wrong etc. so I can learn from it. :-)

Thanks,

Jonathan


Leopold Toetsch

unread,
Oct 28, 2003, 4:07:05 PM10/28/03
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:
> Ah, that's changed, 'cus it used to work with me doing that. :-) So now it
> loads the library, but fails here:-

> dlfunc P0, P1, "MessageBoxA", "llttl"

> With:-

> Parrot VM: PANIC: Unknown signature type!

Your parrot seems to lack JIT support. So all function signatures you
want to use have to be included in src/call_list.txt.

>> BTW - are the nci tests succeeding on Win32:
>>
>> $ make libnci.dll
> That fails with:-

> NMAKE : fatal error U1073: don't know how to make 'parrot'

> libnci$(SO): $(SRC)\nci_test.c parrot$(EXE)


> $(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS) $< -o $@

$(EXE) isn't defined it seems. I've checked in a change to use ${exe}
here.

> Thanks,

> Jonathan

Thank you for your feedback,
leo

Jonathan Worthington

unread,
Oct 28, 2003, 6:28:53 PM10/28/03
to l...@toetsch.at, perl6-i...@perl.org
> Jonathan Worthington <jona...@jwcs.net> wrote:
> > Ah, that's changed, 'cus it used to work with me doing that. :-) So
now it
> > loads the library, but fails here:-
>
> > dlfunc P0, P1, "MessageBoxA", "llttl"
>
> > With:-
>
> > Parrot VM: PANIC: Unknown signature type!
>
> Your parrot seems to lack JIT support. So all function signatures you
> want to use have to be included in src/call_list.txt.
Yes, JIT support is currently broken on Win32, but it hadn't used to be.
I've had a poke around to discover the cause of these errors:-

src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier
src\jit_cpu.c(149) : error C2065: 'EXEC_CALLDISP' : undeclared identifier
src\jit_cpu.c(166) : error C2065: 'RTYPE_DATA' : undeclared identifier

And I believe the following warning to also be relevant:-

src\jit_cpu.c(95) : warning C4013: 'Parrot_exec_add_text_rellocation'
undefined; assuming extern returning int

These are all defined in exec.h, and are contained within a #if EXEC_CAPABLE
block. Win32 is not EXEC_CAPABLE (or certainly, configuring
with --execcapable=1 causes a string of link errors due to unresolved
external symbols, e.g. _Parrot_exec_run). It looks like JIT support has
become dependent on EXEC support - I'm way out of my depth as to whether
that's the way things should be. :-)

> >> BTW - are the nci tests succeeding on Win32:
> >>
> >> $ make libnci.dll
> > That fails with:-
>
> > NMAKE : fatal error U1073: don't know how to make 'parrot'
>
> > libnci$(SO): $(SRC)\nci_test.c parrot$(EXE)
> > $(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS) $< -o $@
>
> $(EXE) isn't defined it seems. I've checked in a change to use ${exe}
> here.

That fixes the original problem, but now I get:-

rem blib/lib/libparrot_s.lib


link -out:parrot.exe -nologo -nodefaultlib -debug -opt:ref,icf -machine:x
86 -debug imcc\main.obj blib/lib/libparrot_s.lib oldnames.lib kernel32.lib
user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib
ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
LINK : warning LNK4075: ignoring /EDITANDCONTINUE due to /OPT specification
NMAKE : warning U4006: special macro undefined : '$<'
link -dll -def:libparrot.def -nologo -debug -o libnci.dll
LINK : warning LNK4044: unrecognized option "o"; ignored
LINK : fatal error LNK1181: cannot open input file "libnci.dll"
NMAKE : fatal error U1077: 'link' : return code '0x49d'
Stop.

> Thank you for your feedback,

You're welcome,

Jonathan


Leopold Toetsch

unread,
Oct 29, 2003, 2:02:17 AM10/29/03
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:

> src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier

Did you recheck that recently, I had committed a change WRT this.

> NMAKE : warning U4006: special macro undefined : '$<'
> link -dll -def:libparrot.def -nologo -debug -o libnci.dll
> LINK : warning LNK4044: unrecognized option "o"; ignored
> LINK : fatal error LNK1181: cannot open input file "libnci.dll"

I'll check the build line again.

> Jonathan

leo

Jonathan Worthington

unread,
Oct 29, 2003, 6:46:57 AM10/29/03
to l...@toetsch.at, perl6-i...@perl.org
> Jonathan Worthington <jona...@jwcs.net> wrote:
>
> > src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier
>
> Did you recheck that recently, I had committed a change WRT this.
I did, and I just did an update now to try it again. Same set of errors
still appear. Again, it's because those constants are defined in an #if
EXEC_CAPABLE block in exec.h, and Win32 doesn't have exec support.

> > NMAKE : warning U4006: special macro undefined : '$<'
> > link -dll -def:libparrot.def -nologo -debug -o libnci.dll
> > LINK : warning LNK4044: unrecognized option "o"; ignored
> > LINK : fatal error LNK1181: cannot open input file "libnci.dll"
>
> I'll check the build line again.

Better, but a space has slipped into the line, resulting in this error:-

link -dll -def:libparrot.def -nologo -debug -out: libnci.dll
src\nci_te
st.obj
LINK : fatal error LNK1146: no argument specified with option "/out:"
NMAKE : fatal error U1077: 'link' : return code '0x47a'
Stop.

The line:-
$(LD_OUT) $@ $(SRC)\nci_test$(O)
Needs to be:-
$(LD_OUT)$@ $(SRC)\nci_test$(O)

Unfortunately, even having done that, it spits out another bunch of errors:-

link -dll -def:libparrot.def -nologo -debug -out:libnci.dll
src\nci_test.obj
libparrot.def : error LNK2001: unresolved external symbol
Parrot_DynOp_core_0_0_11
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
libnci.lib : fatal error LNK1120: 11 unresolved externals
LINK : fatal error LNK1141: failure during build of exports file
NMAKE : fatal error U1077: 'link' : return code '0x475'
Stop.

Jonathan


Leopold Toetsch

unread,
Oct 29, 2003, 7:48:01 AM10/29/03
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:
>> > src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier

>> Did you recheck that recently, I had committed a change WRT this.
> I did, and I just did an update now to try it again. Same set of errors
> still appear. Again, it's because those constants are defined in an #if
> EXEC_CAPABLE block in exec.h, and Win32 doesn't have exec support.

As I can see, all these RTYPE_CON (and other related syms) are enclosed
in '#if EXEC_CAPABLE', so they should never be used.
Can you try to generate a listing after pre-processing (could be -E
switch).

> The line:-
> $(LD_OUT) $@ $(SRC)\nci_test$(O)
> Needs to be:-
> $(LD_OUT)$@ $(SRC)\nci_test$(O)

I'll fix that.

> Unfortunately, even having done that, it spits out another bunch of errors:-

> link -dll -def:libparrot.def -nologo -debug -out:libnci.dll

^^^^^^^^^

That has to be "libnci.def" of course, arghh.

> Jonathan

leo

Mattia Barbon

unread,
Nov 1, 2003, 5:02:00 PM11/1/03
to l...@toetsch.at, perl6-i...@perl.org
Il Tue, 28 Oct 2003 18:51:56 +0100 Leopold Toetsch <l...@toetsch.at> ha scritto:

> Jonathan Worthington <jona...@jwcs.net> wrote:
> > Hi,
>
> > loadlib P1, "user32.dll"
>
> There are 2 errors in that, one is mine :)
> - I didn't use the configure define of PARROT_DLL_EXTENSION
> - Your's is: don't append ".dll" - parrot does it

Somebody might wish to load something not named ".dll". For example
MS HTMLHelp API is located in a file suffixed ".ocx" (which exports
both an ActiveX control and raw C API).

Regards
Mattia

Jonathan Worthington

unread,
Nov 6, 2003, 6:59:18 PM11/6/03
to Mattia Barbon, perl6-i...@perl.org
From: "Mattia Barbon" <mattia...@libero.it>
This is true, and IMHO needs some thought. I'm working on a library that
gives Parrot access to the entire Win32 API. Some of them (related to
printing) are in a library called winspool.drv (note .drv, not .dll).
Parrot adds .dll onto the end of this and, of course, it cannot load it.
I'd be surprised if Win32 was the only OS where there was more than one
possible extension for a shared library.

Thanks,

Jonathan


Jeff Clites

unread,
Nov 6, 2003, 9:19:39 PM11/6/03
to Jonathan Worthington, perl6-i...@perl.org, Mattia Barbon

Yeah, this would likely be a problem on Mac OS X as well, where
loadable bundles can have a variety of extensions. I'm of the opinion
that there's no very good reason to not just have the API take a real
file name (including the extension).

I can imagine enforcing a per-platform extension for parrot bytecode
libs specifically, so that you can write platform-independent user code
which doesn't have to worry about how a parrot add-on lib is named, but
then again it would be just as sensible to have a cross-platform
convention for the extension, and just use the file name even here.

JEff

Leopold Toetsch

unread,
Nov 7, 2003, 2:43:04 AM11/7/03
to Jeff Clites, perl6-i...@perl.org
Jeff Clites <jcl...@mac.com> wrote:
> On Nov 6, 2003, at 3:59 PM, Jonathan Worthington wrote:
>> From: "Mattia Barbon" <mattia...@libero.it>

[ shared file extensions ]

Can we for now do it like:
* if there is a dot in the filepart[1] leave the name as is
* if not append PARROT_DLL_EXTENSION

[1] last thing after '/' or '\\' on Win32

> JEff

leo

Jared Rhine

unread,
Nov 7, 2003, 3:22:53 AM11/7/03
to perl6-i...@perl.org
[Leopold == l...@toetsch.at on Fri, 7 Nov 2003 08:43:04 +0100]

Leopold> [ shared file extensions ]

Leopold> Can we for now do it like:
Leopold> * if there is a dot in the filepart[1] leave the name as is
Leopold> * if not append PARROT_DLL_EXTENSION

Why have any magic at all? Is there a specific advantage to extension
guessing that you have in mind?

It seems just as usable, clear, clean, fast, and unambiguous to say
"load this library", and have it just, uh, load exactly that library.

Having the system try to do what it thinks you want
seems...Windows-esque. The "guessing" part perhaps belongs in the
HLL.

-- ja...@wordzoo.com

"Tiger gotta hunt. Bird gotta fly.
Man gotta sit and wonder why, why, why.
Tiger gotta sleep. Bird gotta land.
Man gotta tell himself he understand." -- Kurt Vonnegut Jr.

Leopold Toetsch

unread,
Nov 7, 2003, 6:30:36 AM11/7/03
to Jared Rhine, perl6-i...@perl.org
Jared Rhine <ja...@wordzoo.com> wrote:
> [Leopold == l...@toetsch.at on Fri, 7 Nov 2003 08:43:04 +0100]

> Leopold> [ shared file extensions ]

> Leopold> Can we for now do it like:
> Leopold> * if there is a dot in the filepart[1] leave the name as is
> Leopold> * if not append PARROT_DLL_EXTENSION

> Why have any magic at all? Is there a specific advantage to extension
> guessing that you have in mind?

loadlib P0, "libcni" # load test library
loadlib P0, "myops_ops" # opcode library
loadlib P0, "subproxy" # class library

These examples should work on all platforms with the configured default
extension. There is no magic or extension guessing involved. We have all
three examples already in the tree.

Of course a Win32 program might load "some.ocx" or a linux program
"ncurses.so" but these are platform-specific libs. I'm speaking of core
modules and such, where no shared extension should be specified in the
source code.

> -- ja...@wordzoo.com

leo

Jonathan Worthington

unread,
Nov 7, 2003, 9:57:33 AM11/7/03
to perl6-i...@perl.org
----- Original Message -----
From: "Leopold Toetsch" <l...@toetsch.at>
> Jeff Clites <jcl...@mac.com> wrote:
> > On Nov 6, 2003, at 3:59 PM, Jonathan Worthington wrote:
> >> From: "Mattia Barbon" <mattia...@libero.it>
>
> [ shared file extensions ]
>
> Can we for now do it like:
> * if there is a dot in the filepart[1] leave the name as is
> * if not append PARROT_DLL_EXTENSION
That sounds reasonable, yes. You could also:-

1) Try loading a library with the name as given
2) If that fails, append PARROT_DLL_EXTENSION and try again
3) If both fail, throw exception/die like now

Or is that a completely crummy idea?

Thanks,

Jonathan

Leopold Toetsch

unread,
Nov 7, 2003, 10:33:50 AM11/7/03
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:
> ----- Original Message -----
> From: "Leopold Toetsch" <l...@toetsch.at>
>>
>> Can we for now do it like:
>> * if there is a dot in the filepart[1] leave the name as is
>> * if not append PARROT_DLL_EXTENSION
> That sounds reasonable, yes. You could also:-

> 1) Try loading a library with the name as given
> 2) If that fails, append PARROT_DLL_EXTENSION and try again
> 3) If both fail, throw exception/die like now

Could be done too. OTOH it can double open times for standard things.
And we will probably search different places in $PARROT_LIB_PATH.

> Jonathan

leo

0 new messages