Building parrot-0.4.1 on Win32
Sisyphus
My first post here. First up, is there a better place to ask questions
relating to the building of parrot ? If so ... where ? If not ... read on.
I'm on Windows 2000, and parrot-0.4.1 builds straight out of the box using
MSVC++ 7.0 (.NET) and nmake. But there's a couple of issues when using MinGW
(gcc-3.4.4) and mingw32-make.
In config/gen/makefiles/root.in I find the line:
MINIPARROT = $(CUR_DIR)/miniparrot$(EXE)
Using MSVC++ and nmake, somewhere along the way, that forward slash gets
converted to a backslash (which is what needs to happen). But using gcc and
mingw32-make, the backslash stays as is. Put simply the problem is that, in
the cmd.exe shell, while '.\some.exe' works fine, './some.exe' always
produces the error:
'.' is not recognized as an internal or external command, operable program
or batch file.
How is that '/' to '\' conversion effected - so that I might apply it to the
MinGW build ?
As a quick hack, when building with MinGW, I simply first change the above
line in 'root.in' to:
MINIPARROT = miniparrot$(EXE)
That avoids the './miniparrot.exe ....' problem I initially experienced, but
the mingw32-make process still fails. Here's how it finishes:
miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
F:\Perl58_M\5.8.8\bin\perl.exe tools/build/parrot_config_c.pl > \
src/parrot_config.c
src/parrot_config.c
F:\Perl58_M\5.8.8\bin\perl.exe tools/build/parrotdef.pl
gcc -o
rrot.exe -s -L"F:\Perl58_M\5.8.8\lib\CORE" -L"F:\MinGW\lib" -Wl,--out-impl
ib,parrot.a \
compilers/imcc/main.o
blib/lib/libparrot.a -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwins
pool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -l
ws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lgmp \
src/parrot_config.o parrot.def
Cannot export Parrot_PMC_get_intval: symbol not defined
Cannot export Parrot_PMC_typenum: symbol not defined
Cannot export Parrot_call_method: symbol not defined
Cannot export Parrot_call_sub: symbol not defined
Creating library file: parrot.a
collect2: ld returned 1 exit status
mingw32-make: *** [parrot.exe] Error 1
The failing command invokes 'gcc' because that's how 'root.in' evaluates
${link}. As a guess, I set ${link} to 'g++', but the error is still the
same.
When building with MSVC++ and nmake, the corresponding command is:
link -out:.\parrot.exe -nologo -nodefaultlib -debug -machine:x86 -debug
compilers\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 ws2_32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
src\parrot_config.obj -def:parrot.def
Comparing the two, I can't really see why the former would fail while the
latter succeeds. I don't think the forward slashes in the former should
matter ... and I don't think the absence of '-lgmp' in the latter accounts
for the difference.
Any advice on how to proceed with this ?
Cheers,
Rob
Jonathan Worthington
> My first post here. First up, is there a better place to ask questions
> relating to the building of parrot ? If so ... where ? If not ... read
> on.
>
> I'm on Windows 2000, and parrot-0.4.1 builds straight out of the box using
> MSVC++ 7.0 (.NET) and nmake.
Yup, as it should.
> But there's a couple of issues when using MinGW
> (gcc-3.4.4) and mingw32-make.
>
Ugh. Not as it should.
> In config/gen/makefiles/root.in I find the line:
>
> MINIPARROT = $(CUR_DIR)/miniparrot$(EXE)
>
> Using MSVC++ and nmake, somewhere along the way, that forward slash gets
> converted to a backslash (which is what needs to happen). But using gcc
> and
> mingw32-make, the backslash stays as is. Put simply the problem is that,
> in
> the cmd.exe shell, while '.\some.exe' works fine, './some.exe' always
> produces the error:
>
> '.' is not recognized as an internal or external command, operable program
> or batch file.
>
> How is that '/' to '\' conversion effected - so that I might apply it to
> the
> MinGW build ?
>
> As a quick hack, when building with MinGW, I simply first change the above
> line in 'root.in' to:
>
> MINIPARROT = miniparrot$(EXE)
>
> That avoids the './miniparrot.exe ....' problem I initially experienced,
> but
I think the right answer is perhaps:
MINIPARROT = $(CUR_DIR)${SLASH}miniparrot$(EXE)
> the mingw32-make process still fails. Here's how it finishes:
>
> miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
> F:\Perl58_M\5.8.8\bin\perl.exe tools/build/parrot_config_c.pl > \
> src/parrot_config.c
> src/parrot_config.c
> F:\Perl58_M\5.8.8\bin\perl.exe tools/build/parrotdef.pl
> gcc -o
>
> ot.exe -s -L"F:\Perl58_M\5.8.8\lib\CORE" -L"F:\MinGW\lib" -Wl,--out-impl
> ib,parrot.a \
> compilers/imcc/main.o
>
> blib/lib/libparrot.a -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwins
> pool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid
> -l
> ws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lgmp \
> src/parrot_config.o parrot.def
> Cannot export Parrot_PMC_get_intval: symbol not defined
> Cannot export Parrot_PMC_typenum: symbol not defined
> Cannot export Parrot_call_method: symbol not defined
> Cannot export Parrot_call_sub: symbol not defined
> Creating library file: parrot.a
> collect2: ld returned 1 exit status
> mingw32-make: *** [parrot.exe] Error 1
>
> The failing command invokes 'gcc' because that's how 'root.in' evaluates
> ${link}. As a guess, I set ${link} to 'g++', but the error is still the
> same.
>
The problem is with symbol export stuff. Quite why it only appears on MinGW
I'm not sure...
> When building with MSVC++ and nmake, the corresponding command is:
>
>
> ink -out:.\parrot.exe -nologo -nodefaultlib -debug -machine:x86 -debug
> compilers\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 ws2_32.lib mpr.lib winmm.lib
> version.lib odbc32.lib odbccp32.lib msvcrt.lib
> src\parrot_config.obj -def:parrot.def
>
> Comparing the two, I can't really see why the former would fail while the
> latter succeeds. I don't think the forward slashes in the former should
> matter ... and I don't think the absence of '-lgmp' in the latter accounts
> for the difference.
>
> Any advice on how to proceed with this ?
>
In 0.4.1 we built up a symbol export list (parrot.def). I got rid of that
since 0.4.1 and the svn trunk now uses the technique of decorating the
symbols in the header files to describe them as needing to be exported. So
I guess one answer is to try the latest Parrot, either from SVN or by
downloading a snapshot:
http://svn.perl.org/snapshots/parrot/
Though if you want to fix up your current source tree then editing
parrot.def and removing "Parrot_PMC_get_intval" etc entries from it might
just make things work.
Thanks,
Jonathan
Sisyphus
----- Original Message -----
From: "Jonathan Worthington"
.
.
> So
> I guess one answer is to try the latest Parrot, either from SVN or by
> downloading a snapshot:
> http://svn.perl.org/snapshots/parrot/
>
Thanks for the reply, Jonathan. A few things came up and I've not been able
to get back until now.
I grabbed the latest from the above link you provided (Feb 16 version, I
believe).
I replaced the '/' with a hardcoded '\' in each of the seven lines in the
'#Executables' section of 'root.in' and that works fine. (There seems to be
a problem in invoking ${SLASH} as per your suggestion - it results somehow
in the creation of '.@miniparrot.exe' and '.parrot.exe'.)
And in 'pge.in' I changed:
PARROT = ..@slash@..@slash@parrot@exe@
to:
PARROT = ..\..\@parrot@exe@
First snag I then hit is:
g++ -shared -s -L"D:\perl58_M\5.8.8\lib\CORE" -L"D:\MinGW\lib" -o
libparrot.dll \
src/charset.o src/encoding.o src/exceptions.o src/global_setup.o
src/interpreter.o src/inter_call.o src/inter_cb.o src/inter_create.o
src/inter_misc.o src/inter_run.o src/register.o src/memory.o src/objects.o
src/packfile.o src/stacks.o src/stack_common.o src/string.o
src/string_primitives.o src/sub.o src/runops_cores.o src/trace.o src/pmc.o
src/pmc_freeze.o src/key.o src/hash.o src/core_pmcs.o src/platform.o
src/jit.o src/jit_cpu.o src/jit_debug.o src/jit_debug_xcoff.o src/intlist.o
src/list.o src/library.o src/global.o src/embed.o src/warnings.o
src/packout.o src/byteorder.o src/debug.o src/smallobject.o src/headers.o
src/hll.o src/dod.o src/gc_ims.o src/gc_gms.o src/exit.o src/misc.o
src/spf_render.o src/spf_vtable.o src/datatypes.o src/fingerprint.o
src/nci.o src/cpu_dep.o src/tsq.o src/longopt.o src/events.o src/thread.o
src/dynext.o src/utils.o src/vtables.o src/pic.o src/pic_jit.o src/mmd.o
src/builtin.o src/extend.o src/extend_vtable.o src/revision.o
src/packfile/pf_items.o src/ops/core_ops.o src/ops/core_ops_switch.o
src/ops/core_ops_cg.o src/ops/core_ops_cgp.o src/exec.o src/exec_cpu.o
src/exec_save.o src/resources.o src/charset/ascii.o src/charset/binary.o
src/charset/iso-8859-1.o src/charset/tables.o src/charset/unicode.o
src/io/io.o src/io/io_buf.o src/io/io_layers.o src/io/io_unix.o
src/io/io_utf8.o src/io/io_mmap.o src/io/io_win32.o src/io/io_stdio.o
src/io/io_passdown.o src/pmc/default.o src/pmc/null.o src/pmc/env.o
src/pmc/perlenv.o src/pmc/key.o src/pmc/random.o src/pmc/unmanagedstruct.o
src/pmc/managedstruct.o src/pmc/delegate.o src/pmc/csub.o src/pmc/compiler.o
src/pmc/exception.o src/pmc/version.o src/pmc/vtablecache.o
src/pmc/parrotio.o src/pmc/parrotlibrary.o src/pmc/parrotinterpreter.o
src/pmc/parrotthread.o src/pmc/lexpad.o src/pmc/timer.o src/pmc/pointer.o
src/pmc/sub.o src/pmc/closure.o src/pmc/continuation.o
src/pmc/retcontinuation.o src/pmc/exception_handler.o src/pmc/coroutine.o
src/pmc/eval.o src/pmc/nci.o src/pmc/float.o src/pmc/integer.o
src/pmc/bigint.o src/pmc/complex.o src/pmc/string.o src/pmc/perlint.o
src/pmc/perlnum.o src/pmc/perlstring.o src/pmc/perlundef.o src/pmc/boolean.o
src/pmc/ref.o src/pmc/sharedref.o src/pmc/array.o src/pmc/floatvalarray.o
src/pmc/intlist.o src/pmc/iterator.o src/pmc/perlarray.o src/pmc/sarray.o
src/pmc/stringarray.o src/pmc/multiarray.o src/pmc/hash.o src/pmc/perlhash.o
src/pmc/orderedhash.o src/pmc/tqueue.o src/pmc/parrotclass.o
src/pmc/parrotobject.o src/pmc/os.o src/pmc/file.o src/pmc/addrregistry.o
src/pmc/bound_nci.o src/pmc/deleg_pmc.o src/pmc/enumerate.o
src/pmc/fixedbooleanarray.o src/pmc/fixedfloatarray.o
src/pmc/fixedintegerarray.o src/pmc/fixedpmcarray.o
src/pmc/fixedstringarray.o src/pmc/lexinfo.o src/pmc/multisub.o
src/pmc/namespace.o src/pmc/none.o src/pmc/pair.o src/pmc/perlscalar.o
src/pmc/resizablebooleanarray.o src/pmc/resizablefloatarray.o
src/pmc/resizableintegerarray.o src/pmc/resizablepmcarray.o
src/pmc/resizablestringarray.o src/pmc/scalar.o src/pmc/slice.o
src/pmc/super.o src/pmc/undef.o src/encodings/fixed_8.o src/encodings/ucs2.o
src/encodings/utf16.o src/encodings/utf8.o compilers/imcc/imcparser.o
compilers/imcc/imclexer.o compilers/imcc/imc.o compilers/imcc/symreg.o
compilers/imcc/instructions.o compilers/imcc/cfg.o
compilers/imcc/reg_alloc.o compilers/imcc/sets.o compilers/imcc/debug.o
compilers/imcc/optimizer.o compilers/imcc/pbc.o compilers/imcc/parser_util.o
compilers/imcc/jit.o compilers/imcc/pcc.o compilers/ast/astparser.o
compilers/ast/astlexer.o compilers/ast/ast_main.o
compilers/ast/node.o -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinsp
ool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lw
s2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lgmp
The input line is too long.
mingw32-make: *** [libparrot.dll] Error 255
Yep ... that's *one* command ... and I'm quite prepared to believe that it
is "too long" :-)
I fudged my way around that by copy'n'pasting that command into a file which
I called 'command.txt' - then open an MSYS (bash) shell and run:
`cat command.txt`
That also works fine ... then, back in the 'cmd.exe' shell run
'mingw32-make' again.
Thankfully, that process now succeeds.
Running 'mingw3-make test' runs pretty much as for 'nmake test' (see report
below) except that it hangs when it gets to the 't/dynoplibs/myops' tests.
When I kill the process and re-run 'mingw32-make test' I get:
D:\parrot>mingw32-make test
Compiling with:
xx.c
gcc -I./include -s -O2 -DWIN32 -g -Wall -Wstrict-prototypes -Wmiss
-Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrit
gregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-non
at-security -Wpacked -Wdisabled-optimization -mno-accumulate-outgo
shadow -falign-functions=16 -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO
xx.c
mingw32-make -C docs
mingw32-make[1]: Entering directory `D:/parrot/docs'
D:\perl58_M\5.8.8\bin\perl.exe -MExtUtils::Command -e mkpath ops
mingw32-make[1]: Leaving directory `D:/parrot/docs'
mingw32-make -C src/dynpmc
mingw32-make[1]: Entering directory `D:/parrot/src/dynpmc'
mingw32-make[1]: Leaving directory `D:/parrot/src/dynpmc'
mingw32-make -C src/dynoplibs
mingw32-make[1]: Entering directory `D:/parrot/src/dynoplibs'
Copy myops_ops.dll failed (0)
mingw32-make[1]: *** [all] Error 255
mingw32-make[1]: Leaving directory `D:/parrot/src/dynoplibs'
mingw32-make: *** [dynoplibs.dummy] Error 2
The same error is repeated when I run 'mingw32-make install'.
#############################################
Wrt Visual Studio (I'm using 7.0 .NET, btw) it's pretty much the same as
with 0.4.1. It compiles fine but there are some test failures:
Failed Test Stat Wstat Total Fail Failed List of Failed
----------------------------------------------------------------------------
---
t/configure/step.t 2 512 19 2 10.53% 10-11
t/op/arithmetics.t 1 256 26 1 3.85% 7
t/pmc/env.t 2 512 12 2 16.67% 9-10
t/pmc/float.t 1 256 45 1 2.22% 26
t/pmc/perlnum.t 1 256 55 1 1.82% 47
t/src/basic.t 3 768 3 3 100.00% 1-3
t/src/compiler.t 1 256 1 1 100.00% 1
t/src/exit.t 3 768 3 3 100.00% 1-3
t/src/extend.t 13 3328 13 13 100.00% 1-13
t/src/hash.t 11 2816 11 11 100.00% 1-11
t/src/intlist.t 4 1024 4 4 100.00% 1-4
t/src/io.t 20 5120 20 20 100.00% 1-20
t/src/list.t 2 512 2 2 100.00% 1-2
t/src/sprintf.t 3 768 3 3 100.00% 1-3
9 tests and 732 subtests skipped.
Failed 14/228 test scripts, 93.86% okay. 67/4851 subtests failed, 98.62%
okay.
NMAKE : fatal error U1077: 'F:\perlvc7\5.8.8\bin\perl.exe' : return code
'0xff'
Stop.
It seems basically functional:
F:\pascrpt>parrot hello.pir
Hello world!
F:\pascrpt>parrot -o hello.pasm hello.pir
F:\pascrpt>parrot hello.pasm
Hello world!
But when I try to run 'japh1.pasm' (which I copied from the examples/japh)
folder I get:
F:\pascrpt>parrot japh1.pasm
error:imcc:syntax error, unexpected IDENTIFIER, expecting PARROT_OP
in file 'japh1.pasm' line 10
Same error happens on my linux (Mandrake-9.1) box. Looks like there are
'pasm' files ... and there are 'pasm' files :-)
I'll continue to plug away at this and report back as I make progress (could
take a while). If anyone wants to offer some direction in that regards, then
that's well and good. However, my questions fall into the "dumbarse newbie"
category .... and I'm mindful of the fact that I
perhaps ought *not* be asking them on what appears to be a developer list.
Oh .... one other thing .... on Linux I had to add (the standard location)
/usr/local/lib to LD_LIBRARY_PATH. I've not had to do that before ... and
the README suggests that I shouldn't have to do it wrt parrot. It says:
"But please note that dynamic libs will not be found for non-standard
locations unless you set LD_LIBRARY_PATH or similar."
Cheers,
Rob
Nick Glencross
> Oh .... one other thing .... on Linux I had to add (the standard location)
> /usr/local/lib to LD_LIBRARY_PATH. I've not had to do that before ... and
> the README suggests that I shouldn't have to do it wrt parrot. It says:
>
> "But please note that dynamic libs will not be found for non-standard
> locations unless you set LD_LIBRARY_PATH or similar."
Most distributions of Linux will have /usr/local/lib in
/etc/ld.so.conf already since it is normally considered a standard
location. Have you got an entry?
Cheers,
Nick
Sisyphus
Yes, /usr/local/lib is already in /etc/ld.so.conf.
$LD_LIBRARY_PATH is initially empty. If I don't add '/usr/local/lib' to it,
then when I run 'parrot hello.pir', I get (transcribed):
parrot: error while loading shared libraries: libparrot.so.0.4.1: cannot
open shared object file: No such file or directory
Browsing through /usr/local/lib with 'kwrite', I notice that the
permissions for 'libparrot.so.0.4.1' are -rwxr-xr-x, whereas for many of the
other shared libraries the permissions are 'lrwxr-xr-x'. I don't know if
that's relevant to the issue .... I don't know what the first permission is,
or how to change it. (I don't use linux all that much.)
Cheers,
Rob
Joshua Hoblitt
> Yes, /usr/local/lib is already in /etc/ld.so.conf.
Perhaps you need to run `ldconfig` as root.
> $LD_LIBRARY_PATH is initially empty. If I don't add '/usr/local/lib' to it,
> then when I run 'parrot hello.pir', I get (transcribed):
>
> parrot: error while loading shared libraries: libparrot.so.0.4.1: cannot
> open shared object file: No such file or directory
It sounds like your build of libparrot is linked against something under
/usr/local/lib that your linker doesn't know about. That could be
because the linker doesn't know it's supposed to search /usr/local/lib
or that it's database is out of date. Either way it's an issue with your
local system.
> Browsing through /usr/local/lib with 'kwrite', I notice that the
> permissions for 'libparrot.so.0.4.1' are -rwxr-xr-x, whereas for many of the
> other shared libraries the permissions are 'lrwxr-xr-x'. I don't know if
> that's relevant to the issue .... I don't know what the first permission is,
> or how to change it. (I don't use linux all that much.)
That's not relevant.
Cheers,
-J
--
Nick Glencross
> On Tue, Feb 21, 2006 at 10:06:36AM +1100, Sisyphus wrote:
> > Yes, /usr/local/lib is already in /etc/ld.so.conf.
>
> Perhaps you need to run `ldconfig` as root.
>
> > $LD_LIBRARY_PATH is initially empty. If I don't add '/usr/local/lib' to it,
> > then when I run 'parrot hello.pir', I get (transcribed):
> >
> > parrot: error while loading shared libraries: libparrot.so.0.4.1: cannot
> > open shared object file: No such file or directory
Which copy of perl is giving this error? Is it one installed under
/usr/local or the one that is in the build directory? What do you get
if you run 'ldd' on it?
Cheers,
Nick
Sisyphus
On 2/20/06, Joshua Hoblitt <jhob...@ifa.hawaii.edu> wrote:
> > Yes, /usr/local/lib is already in /etc/ld.so.conf.
>
> Perhaps you need to run `ldconfig` as root.
Yep - that takes care of it.
Cheers,
Rob