[PATCH] Get string.c to compile in MS VC++
Hi, I'm having a crack at getting the ICU changes building on Win32. Here's the first step. string.c did some C99 stuff:- * Declared variables at places other than the top of a block * Used uint8_t, uint16_t, uint32_t, which we don't exists in MS VC++ The attached patch fixes these plus another warning. For the /uint\d+_t/ ones, I used Parrot_UInt2 and Parrot_UInt4, and added a Parrot_UInt1 in config.h.in, which is hard-coded to be an unsigned char for now. I'm not sure if this was the Right Thing to do, but it works. ;-) Hope this helps, Jonathan string_c.diff Description: Binary data
Re: [PATCH] Get string.c to compile in MS VC++
On Apr 9, 2004, at 3:26 PM, Jonathan Worthington wrote: I'm having a crack at getting the ICU changes building on Win32. Great--thanks! Here's the first step. string.c did some C99 stuff:- * Declared variables at places other than the top of a block Sorry about that. * Used uint8_t, uint16_t, uint32_t, which we don't exists in MS VC++ The attached patch fixes these plus another warning. For the /uint\d+_t/ ones, I used Parrot_UInt2 and Parrot_UInt4, and added a Parrot_UInt1 in config.h.in, which is hard-coded to be an unsigned char for now. I'm not sure if this was the Right Thing to do, but it works. ;-) I think it's the right thing. I figured that the uintX_t would need to be changed to something config-able, but I didn't realize we already had types in place (or most of them) which would do the job. So thanks again for taking care of that! JEff
Re: [PATCH] Get string.c to compile in MS VC++
Jonathan Worthington wrote: * Used uint8_t, uint16_t, uint32_t, which we don't exists in MS VC++ Thanks applied. C99ish decls were alredy fixed. Jonathan leo
Re: [PATCH] Get string.c to compile in MS VC++
> On Apr 9, 2004, at 3:26 PM, Jonathan Worthington wrote: > > > I'm having a crack at getting the ICU changes building on Win32. > > Great--thanks! > Here's the next step. Now we actually get through the build process, building ICU along the way and linking the .lib files into the final Parrot executable. Unfortunately, nmake test shows that I've screwed something up... -- Failed Test Status Wstat Total Fail Failed List of Failed imcc\t\syn\clash.t 1 256151 6.67% 13 t\op\arithmetics.t12 307220 12 60.00% 7-18 t\op\ifunless.t2 512 62 33.33% 2, 5 t\op\integer.t 1 256391 2.56% 4 t\op\jit.t 1 256581 1.72% 54 t\op\jitn.t2 512102 20.00% 9-10 t\op\number.t 32 819238 32 84.21% 1-24, 27, 29, 31, 34-38 t\op\stacks.t 4 1024564 7.14% 17, 50-52 t\op\string.t 3 768 1323 2.27% 94-95, 102 t\op\trans.t 17 435218 17 94.44% 1-7, 9-18 t\pmc\boolean.t1 256 71 14.29% 2 t\pmc\delegate.t 2 512102 20.00% 5-6 t\pmc\dumper.t 1 256131 7.69% 5 t\pmc\float.t 5 1280 95 55.56% 1, 6-9 t\pmc\freeze.t 1 256131 7.69% 3 t\pmc\io.t 2 512232 8.70% 9, 18 t\pmc\managedstruct.t 1 256 51 20.00% 2 t\pmc\object-meths.t 191 5.26% 17 t\pmc\orderedhash.t1 256181 5.56% 16 t\pmc\perlarray.t 2 512262 7.69% 2-3 t\pmc\perlhash.t 1 256331 3.03% 33 t\pmc\perlint.t6 1536276 22.22% 16-20, 25 t\pmc\perlnum.t 20 512036 20 55.56% 4, 8-10, 13-14, 16-25, 27, 33-34, 36 t\pmc\perlstring.t 7 1792337 21.21% 1-2, 7, 10, 12, 14, 17 t\pmc\pmc.t 35 896092 35 38.04% 8, 12, 15-16, 18-19, 21- 24, 26, 31-33, 36, 39-40, 47, 49, 56, 58, 63, 65- 75, 77, 92 t\pmc\ref.t1 256 61 16.67% 4 t\pmc\sort.t 1 256 91 11.11% 6 t\pmc\sys.t1 256 11 100.00% 1 t\src\string.t 1 256 11 100.00% 1 2 tests and 87 subtests skipped. Failed 29/100 test scripts, 71.00% okay. 165/1481 subtests failed, 88.86% okay. -- I don't have time to dig into this right now, but if anyone can spot an obvious pattern in these failures or point me at what I did wrong, that'd be great. One thing that does stand out to me is that icudata.lib is only 2 KB, and another is that I didn't get an icuuc.lib, but rather an icuucd.lib. I'm guessing that as it linked properly it contains the appropriate symbols, though. Now for the patch. I've attached my changes to icu.pl. Basically it's just more stuff in the MS VC++ specific section of icu.pl. There are also some files missing in CVS that we need (they were moved into the attic after being considered unrequired, but it turns out they are for Win32 building). I've attached a patch to put them back in. Note that as some parts of ICU in the parrot tree have been removed, I had to modify the .dsw file so it didn't contain references to the related project files. So, to be totally clear, the .dsw file is different from what would be in the standard ICU package. I hope this is a move in the right direction. I guess building and failing some tests is better than not building at all. ;-) Happy Easter, Jonathan icu.pl.patch Description: Binary data icuwin32missing.patch Description: Binary data
Re: [PATCH] Get string.c to compile in MS VC++
On Apr 11, 2004, at 4:52 PM, Jonathan Worthington wrote:
On Apr 9, 2004, at 3:26 PM, Jonathan Worthington wrote:
I'm having a crack at getting the ICU changes building on Win32.
Great--thanks!
Here's the next step. Now we actually get through the build process,
building ICU along the way and linking the .lib files into the final
Parrot
executable.
Awesome!
Unfortunately, nmake test shows that I've screwed something
up...
--
Failed Test Status Wstat Total Fail Failed List of Failed
---
-
t\op\integer.t 1 256391 2.56% 4
t\op\number.t 32 819238 32 84.21% 1-24, 27, 29,
31,
34-38
--
I don't have time to dig into this right now, but if anyone can spot an
obvious pattern in these failures or point me at what I did wrong,
that'd be
great. One thing that does stand out to me is that icudata.lib is
only 2
KB, and another is that I didn't get an icuuc.lib, but rather an
icuucd.lib.
I'm guessing that as it linked properly it contains the appropriate
symbols,
though.
Yep, the pattern I think I see is that tests which involve floats
(except for 0.0) are failing, which is what would happen if ICU can't
find it's data. (Because, it either ends up thinking that nothing is a
digit character, or that they all have digit value zero.) I'll have to
add a quick test inside string_init to detect this case, so that we can
blow up instead of misbehaving.
As for your libraries, I'm not sure about the naming of icuucd.lib, but
it's probably okay--ICU has a bunch of different options for naming
libraries, and it's possible that the "d" is for "dynamic", or
something. (As long as they are being found at runtime, it's probably
okay.) The icudata.lib is tiny because it's just a stub--the data can
be built into that lib, but my config parameters have it building a
separate archive (".dat") file (in part because it builds much faster,
but also because that let you add/remove encodings and locales without
a rebuild).**
See if you have a ".dat" file (or a bunch of individual files) in
blib/lib/icu/2.6.1 (relative to your parrot source root). If not, then
that's what's going on. Right now, I have that path hard-coded--of
course I need to pull that out into a config--but it probably means
that either the data files aren't getting created, or just that they
are in a different location. Glancing at your icu.pl patch, it may just
be missing moving the .dat file (or, maybe creating it too).
Now for the patch. I've attached my changes to icu.pl. Basically
it's just
more stuff in the MS VC++ specific section of icu.pl. There are also
some
files missing in CVS that we need (they were moved into the attic after
being considered unrequired, but it turns out they are for Win32
building).
I've attached a patch to put them back in. Note that as some parts of
ICU
in the parrot tree have been removed, I had to modify the .dsw file so
it
didn't contain references to the related project files. So, to be
totally
clear, the .dsw file is different from what would be in the standard
ICU
package.
I hope this is a move in the right direction. I guess building and
failing
some tests is better than not building at all. ;-)
Definitely!
JEff
[**] There are 4 or so options for how to package the ICU data--into a
dynamic library, into an archive library, as a bunch of separate files,
or as a single file. Any should work, but the last two are faster to
build, and a bit more flexible.
Re: [PATCH] Get string.c to compile in MS VC++
On Apr 11, 2004, at 7:05 PM, Jeff Clites wrote: On Apr 11, 2004, at 4:52 PM, Jonathan Worthington wrote: On Apr 9, 2004, at 3:26 PM, Jonathan Worthington wrote: I'm having a crack at getting the ICU changes building on Win32. -- Failed Test Status Wstat Total Fail Failed List of Failed -- -- t\op\integer.t 1 256391 2.56% 4 t\op\number.t 32 819238 32 84.21% 1-24, 27, 29, 31, 34-38 -- Yep, the pattern I think I see is that tests which involve floats (except for 0.0) are failing, which is what would happen if ICU can't find it's data. (Because, it either ends up thinking that nothing is a digit character, or that they all have digit value zero.) I'll have to add a quick test inside string_init to detect this case, so that we can blow up instead of misbehaving. ... See if you have a ".dat" file (or a bunch of individual files) in blib/lib/icu/2.6.1 (relative to your parrot source root). If not, then that's what's going on. Right now, I have that path hard-coded--of course I need to pull that out into a config I've submitted a patch, [perl #28473], which makes that location configurable (still defaulting to blib/lib/icu/2.6.1), and which will cause parrot to complain if it can't find the necessary data files. That should also cause the build to fail near the end if something is wrong, when it tries to create library/config.fpmc. That doesn't fix your case, but at least it should make such failures clearer, and easier to fix. JEff
Re: [PATCH] Get string.c to compile in MS VC++
> > See if you have a ".dat" file (or a bunch of individual files) in > blib/lib/icu/2.6.1 (relative to your parrot source root). If not, then > that's what's going on. Right now, I have that path hard-coded--of > course I need to pull that out into a config--but it probably means > that either the data files aren't getting created, or just that they > are in a different location. Glancing at your icu.pl patch, it may just > be missing moving the .dat file (or, maybe creating it too). > They are missing, and in fact weren't even being created. Turns out I'd somehow managed to miss a line out in the makefile, namely the one that made the data. D'oh. I added it in, but this gave rise to new problems. The .mak file (in icu/source/data) was missing some paths so some of the tools were not being found. That was easily fixed, and now it gets quite a way through making the data, until it hits a point where it starts giving errors like this:- -- Making Locale Resource Bundle files ..\..\locales\root.txt:39: warning: %Collation could not be constructed from CollationElements - check context! ..\..\locales\root.txt:37: parse error. Stopped parsing with U_INVALID_FORMAT_ERROR couldn't parse the file ..\..\locales\root.txt. Error:U_INVALID_FORMAT_ERROR ..\..\locales\ar.txt:16: warning: %Collation could not be constructed from CollationElements - check context! ..\..\locales\ar.txt:14: parse error. Stopped parsing with U_INVALID_FORMAT_ERROR couldn't parse the file ..\..\locales\ar.txt. Error:U_INVALID_FORMAT_ERROR ..\..\locales\ca.txt:12: warning: %Collation could not be constructed from CollationElements - check context! ..\..\locales\ca.txt:10: parse error. Stopped parsing with U_INVALID_FORMAT_ERROR -- Any ideas? > [**] There are 4 or so options for how to package the ICU data--into a > dynamic library, into an archive library, as a bunch of separate files, > or as a single file. Any should work, but the last two are faster to > build, and a bit more flexible. > Looking at the makefile, I believe it would package the data in each of these ways, then we'd just copy the .dat into the appropriate place. Once I've got it to actually work, I'll see if I can get it down to generating the .dat only. Jonathan
Re: [PATCH] Get string.c to compile in MS VC++
On Apr 12, 2004, at 5:33 AM, Jonathan Worthington wrote: See if you have a ".dat" file (or a bunch of individual files) in blib/lib/icu/2.6.1 (relative to your parrot source root). If not, then that's what's going on. Right now, I have that path hard-coded--of course I need to pull that out into a config--but it probably means that either the data files aren't getting created, or just that they are in a different location. Glancing at your icu.pl patch, it may just be missing moving the .dat file (or, maybe creating it too). They are missing, and in fact weren't even being created. Turns out I'd somehow managed to miss a line out in the makefile, namely the one that made the data. D'oh. I added it in, but this gave rise to new problems. The .mak file (in icu/source/data) was missing some paths so some of the tools were not being found. That was easily fixed, and now it gets quite a way through making the data, until it hits a point where it starts giving errors like this:- -- Making Locale Resource Bundle files ..\..\locales\root.txt:39: warning: %Collation could not be constructed from CollationElements - check context! ..\..\locales\root.txt:37: parse error. Stopped parsing with U_INVALID_FORMAT_ERROR couldn't parse the file ..\..\locales\root.txt. Error:U_INVALID_FORMAT_ERROR ..\..\locales\ar.txt:16: warning: %Collation could not be constructed from CollationElements - check context! ..\..\locales\ar.txt:14: parse error. Stopped parsing with U_INVALID_FORMAT_ERROR couldn't parse the file ..\..\locales\ar.txt. Error:U_INVALID_FORMAT_ERROR ..\..\locales\ca.txt:12: warning: %Collation could not be constructed from CollationElements - check context! ..\..\locales\ca.txt:10: parse error. Stopped parsing with U_INVALID_FORMAT_ERROR -- Any ideas? This error was showing up on Linux, and I was able to get it to happen for me by running the genrb tool with a parameter (or env. variable) missing. (Probably, the cause in the Linux case was actually something else.) Take a look at my first post in the "Build problems in i386 linux" thread. One cause of this error is that the 'genrb' tool (built before this point) can't find a data file it needs--the file is icudt26b_ucadata.icu (possibly with a different prefix for you), and is probably in the icu/source/data/out/build directory. On Unix systems, it's located via the "ICU_DATA" env. variable (which apparently has to end with a slash), which the Makefile in icu/source/data sets up, or it can be passed via a "-i" argument to 'genrb' (either way, pointing to the directory containing that file). So take a look and see how that tool is being invoked in the build process, and whether a parameter is missing (or pointed to the wrong place). That's my bet for what's going on. (The Linux case was only failing on one if the files, but it sounds like you're failing on all of them, which is the behavior I'd expect if this is the problem.) But, we're getting there! JEff
ICU Building On Win32 (was Re: [PATCH] Get string.c to compile in MS VC++)
"Jeff Clites" <[EMAIL PROTECTED]> wrote: > On Apr 12, 2004, at 5:33 AM, Jonathan Worthington wrote: > > >> > >> See if you have a ".dat" file (or a bunch of individual files) in > >> blib/lib/icu/2.6.1 (relative to your parrot source root). If not, then > >> that's what's going on. Right now, I have that path hard-coded--of > >> course I need to pull that out into a config--but it probably means > >> that either the data files aren't getting created, or just that they > >> are in a different location. Glancing at your icu.pl patch, it may > >> just > >> be missing moving the .dat file (or, maybe creating it too). > >> > > They are missing, and in fact weren't even being created. Turns out > > I'd > > somehow managed to miss a line out in the makefile, namely the one > > that made > > the data. D'oh. > > > > I added it in, but this gave rise to new problems. The .mak file (in > > icu/source/data) was missing some paths so some of the tools were not > > being > > found. That was easily fixed, and now it gets quite a way through > > making > > the data, until it hits a point where it starts giving errors like > > this:- > > > > -- > > Making Locale Resource Bundle files > > ..\..\locales\root.txt:39: warning: %Collation could not be > > constructed from > > CollationElements - check context! > > ..\..\locales\root.txt:37: parse error. Stopped parsing with > > U_INVALID_FORMAT_ERROR > > couldn't parse the file ..\..\locales\root.txt. > > Error:U_INVALID_FORMAT_ERROR > > ..\..\locales\ar.txt:16: warning: %Collation could not be constructed > > from > > CollationElements - check context! > > ..\..\locales\ar.txt:14: parse error. Stopped parsing with > > U_INVALID_FORMAT_ERROR > > couldn't parse the file ..\..\locales\ar.txt. > > Error:U_INVALID_FORMAT_ERROR > > ..\..\locales\ca.txt:12: warning: %Collation could not be constructed > > from > > CollationElements - check context! > > ..\..\locales\ca.txt:10: parse error. Stopped parsing with > > U_INVALID_FORMAT_ERROR > > -- > > > > Any ideas? > > This error was showing up on Linux, and I was able to get it to happen > for me by running the genrb tool with a parameter (or env. variable) > missing. (Probably, the cause in the Linux case was actually something > else.) > > Take a look at my first post in the "Build problems in i386 linux" > thread. One cause of this error is that the 'genrb' tool (built before > this point) can't find a data file it needs--the file is > icudt26b_ucadata.icu (possibly with a different prefix for you), and is > probably in the icu/source/data/out/build directory. On Unix systems, > it's located via the "ICU_DATA" env. variable (which apparently has to > end with a slash), which the Makefile in icu/source/data sets up, or it > can be passed via a "-i" argument to 'genrb' (either way, pointing to > the directory containing that file). So take a look and see how that > tool is being invoked in the build process, and whether a parameter is > missing (or pointed to the wrong place). > > That's my bet for what's going on. (The Linux case was only failing on > one if the files, but it sounds like you're failing on all of them, > which is the behavior I'd expect if this is the problem.) > Yup, that was it. There were a few other little issues with the makefile that I had to deal with, but it all appears to be working now. There are only 3 tests failing, and as I remember they were ones that failed before the big ICU patch. I've attached the patches, and (fingers crossed) this will get Parrot going on Win32 again. Summary of changes:- * Add source/allinone/all/all.dsp (which was moved to the attic previously). * Add a modified source/allinone/allinone.dsw (which was moved to the attic previously). Changes are due to the fact that we do not have everything the full ICU tree would have. * Modify config/gen/icu.pl to write the makefile entries for building ICU on Win32 and ensure .dsp files have proper Win32 line endings (MS VC++ is very fussy about this). * Modify icu/source/data/makedata.mak to correct a few path issues and remove parts relating to things we don't have on the ICU source tree. Jonathan win32icu.patch Description: Binary data icuwin32missing.patch Description: Binary data
Re: ICU Building On Win32 (was Re: [PATCH] Get string.c to compile in MS VC++)
At 8:46 PM +0100 4/12/04, Jonathan Worthington wrote: I've attached the patches, and (fingers crossed) this will get Parrot going on Win32 again. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
