Thanks for the reply. Readme.Win32 should have a notice about building in
anything other than Visual Studio 6. Since 'msdev' is hardcoded inside the
ICU build stuff, it *won't build on anything other than Visual Studio 6*.
For anyone interested, I've written step-by-step instructions on how to
build it at
http://dotnetjunkies.com/WebLog/sriram/archive/2005/01/28/49040.aspx .
>Would you care to retrace your steps carefully from a clean CVS HEAD,
>and provide a detailed description (eg, console in and output)?
Doing so.I have Windows XP SP2 with Visual Studio 2003. My ICU binaries are
at D:/lib/icu/bin and /lib respectively. Parrot is at D:/parrot/parrot. For
anyone building ICU from source on Win32, make sure you do a release build
as the filenames are different for the debug build.
Attempt #1
---
First, Readme.Win32 asks us to use " perl Configure.pl
--icushared="C:\usr\lib\icu\lib\icudata.lib C:\usr\lib\icu\lib\icuuc.lib"
--icuheaders="C:\usr\lib\icu\include""
So I run
D:\parrot\parrot>perl Configure.pl --icushared="D:\lib\icu\lib\icudata.lib
D:\lib\icu\lib\icuuc.lib" --icuheaders="D:\lib\icu\include"
After configuring, I run nmake.
D:\parrot\parrot\nmake
Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C)
Microsoft Corporation. All rights reserved.
Compiling with:
xx.c
cl -nologo -GF -W3 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
-DNO_HASH_SE D -Zi -I./include -ID:\lib\icu\include -DHAS_JIT -DI386 -I. -Fo
xx.obj -c xx.c
A bunch of warnings later (about unreferenced local variables,etc), I get
this
.\parrot -o runtime\parrot\include\parrotlib.pbc
runtime\parrot\library\ parrotlib.imc
This throws an access violation and lands me in the debugger. The problem
here is in string.c
data_dir = Parrot_getenv("PARROT_ICU_DATA_DIR", &free_data_dir);
if (data_dir == NULL) {
const char *prefix;
char *p, *build_path;
build_path = data_dir = const_cast(DEFAULT_ICU_DATA_DIR);
/*
* if the installed --prefix directory exists then use it
*/
prefix = Parrot_get_runtime_prefix(interpreter, NULL);
if (prefix) {
p = strstr(build_path, "blib");/* .../blib/lib/...
*/
assert(p);
--p;/* slash or backslash */
data_dir = mem_sys_allocate(strlen(prefix) + strlen(p) + 1);
strcpy(data_dir, prefix);
strcat(data_dir, p);
free_data_dir = 1;
}
}
The problem is that data_dir is a blank string - PARROT_ICU_DATA_DIR seems
to have a null string which causes it to finally blow up in the strlen(p)
call. What is interesting is that the assert doesn't get called at all - so
there's something wrong with the compiler switches as well.
Attempt #2
--
Now, the next attempt I made was by passing --icudatadir also (as
D:/lib/icu/source/data/out). This time, PARROT_ICU_DATA_DIR gets assigned
properly but the code blows up in the same section. The reason this time is
that there is no "blib" anywhere in the path of the datadir - which causes
the strstr to return 0x0 which becomes 0xF after p--. I'm not really
sure why the data directory must be under "blib" though - and if so, what is
the point of a command line paramter to specify where it should be?
Attempt #3
---
This time, I copied the contents of my data directory into the blib folder
and configured it like this
D:/parrot/parrot>perl Configure.pl --icushared="D:\lib\icu\lib\icudata.lib
D:\lib\icu\lib\icuuc.lib" --icuheaders="D:\lib\icu\include"
--icudatadir="D:\parrot\parrot\blib\lib"
This time, the build succeeds (as "blib" is present in the datadir path).
However, the linking during the 'nmake test' fails with the same error you
saw.
Attempt #4
---
I removed nci_dlvar_vv from libnci_test.def and built again.This lets me
actually run the tests. My output for the tests are identical to yours (with
the nci tests failing).
Thanks,
Sriram
