NCI Broken On Win32
Jonathan Worthington
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
> 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
>
> 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
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
> 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
> > 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.
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
> 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
>
> > src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier
>
> Did you recheck that recently, I had committed a change WRT this.
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
>> > 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
> 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
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
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
> 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
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.
"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
> [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
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
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
> ----- Original Message -----
> From: "Leopold Toetsch" <l...@toetsch.at>
>>
>> * 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