"Sisyphus" <[EMAIL PROTECTED]> wrote:
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.

Welcome to the list and yes, you're in the right place.  :-)

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

Reply via email to