The Saga of Building Parrot : ICU
Jack J. Woehr
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc --icuplatform=sparc-sun-solaris2.9
The build bombs in:
string_set_data_directory: ICU data files not found(apparently) for directory [/usr/local/uplevel/blib/lib/icu/2.6.1]make: *** [runtime/parrot/include/parrotlib.pbc] Error 40
Is it best to just build ICU separately?
--
Jack J. Woehr # Ordinator consistetvr,
PO Box 51, Golden, CO 80402 # redintegrandvs tandem
http://www.well.com/~jax # tangenda qvodvis clavis.
Nicholas Clark
> Okay, I now configured
>
> perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc --icuplatform=sparc-sun-solaris2.9
>
> The build bombs in:
>
> string_set_data_directory: ICU data files not found(apparently) for directory [/usr/local/uplevel/blib/lib/icu/2.6.1]make: *** [runtime/parrot/include/parrotlib.pbc] Error 40
Does the directory /usr/local/uplevel exist at this point?
Nicholas Clark
Jack J. Woehr
Yes, it's empty, just created it the purpose of the build.
Jeff Clites
> Nicholas Clark wrote:
>
>> On Sun, Nov 07, 2004 at 01:17:28PM -0700, Jack J. Woehr wrote:
>>> Okay, I now configured
>>>
>>> perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc
>>> --cxx=gcc --icuplatform=sparc-sun-solaris2.9
>>>
>>> The build bombs in:
>>>
>>> string_set_data_directory: ICU data files not found(apparently)
>>> for directory [/usr/local/uplevel/blib/lib/icu/2.6.1]make: ***
>>> [runtime/parrot/include/parrotlib.pbc] Error 40
>>
>> Does the directory /usr/local/uplevel exist at this point?
>
> Yes, it's empty, just created it the purpose of the build.
Try building without specifying a --prefix to Configure.pl. The problem
is that in the last part of the build process, parrot gets run to
compile some stuff into bytecode, but since you haven't installed yet,
this fails because some necessary files have not yet been moved into
their final location. I think that's what's going on. It's definitely a
problem with the configuration process, but the "install" functionality
is new, and still a bit rough.
So, doing "make install" without first doing "make" might work in the
case of a --prefix specified, because it might take this into account.
But if you just "make" and don't install (and don't specify a
--prefix), then it should work--it's just that your build products will
still be inside of your source tree, rather than being installed
anywhere. But for experimenting, this should be okay.
JEff
Nicholas Clark
> On Nov 7, 2004, at 3:20 PM, Jack J. Woehr wrote:
>
> >Nicholas Clark wrote:
> >
> >>On Sun, Nov 07, 2004 at 01:17:28PM -0700, Jack J. Woehr wrote:
> >>>Okay, I now configured
> >>>
> >>> perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc
> >>>--cxx=gcc --icuplatform=sparc-sun-solaris2.9
> >>>
> >>>The build bombs in:
> >>>
> >>> string_set_data_directory: ICU data files not found(apparently)
> >>>for directory [/usr/local/uplevel/blib/lib/icu/2.6.1]make: ***
> >>>[runtime/parrot/include/parrotlib.pbc] Error 40
> >>
> >>Does the directory /usr/local/uplevel exist at this point?
> >
> >Yes, it's empty, just created it the purpose of the build.
>
> Try building without specifying a --prefix to Configure.pl. The problem
> is that in the last part of the build process, parrot gets run to
> compile some stuff into bytecode, but since you haven't installed yet,
> this fails because some necessary files have not yet been moved into
> their final location. I think that's what's going on. It's definitely a
> problem with the configuration process, but the "install" functionality
> is new, and still a bit rough.
Yes, we're getting it wrong at the moment, in that the test is being done
on the presence topmost directory, rather than on the presence of a deeper
directory (and probably shouldn't be a test at all - the build process
should override to always use the uninstalled files)
So I think that deleting the empty directory /usr/local/uplevel for the
duration of the build should solve your problem.
Nicholas Clark
Jack J. Woehr
> So I think that deleting the empty directory /usr/local/uplevel for the
> duration of the build should solve your problem.
Removed the dir, finished the build, recreated the dir, and make install worked.
Now on to actually *trying out* Parrot ... as a former ANSForth Technical Committee
member, think I'll try the Forth first :-)
Thanks everyone for prompt help over a weekend.
Leopold Toetsch
> Okay, I now configured
> perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc --icuplatform=sparc-sun-solaris2.9
> The build bombs in:
> string_set_data_directory: ICU data files not found(apparently) for directory [/usr/local/uplevel/blib/lib/icu/2.6.1]make: *** [runtime/parrot/include/parrotlib.pbc] Error 40
Argh (sorry not you), we have really to do something against that ever
and ever resurrecting ICU build troubles.
What's the state of ICU 3.0?
leo
Jeff Clites
ICU 3.0 worked fine for me as a drop-in replacement (built
independently, not as part of the Parrot build), but I thinks that's
not the main issue--it's the at-runtime location of resources that is
the problem. I have an idea about how we could be doing that better, in
particular in the case of using a dynamic libparrot (in which case
parrot-specific resources should really be located relative to the
library, not the executable). Basically, dladdr() lets you find out at
runtime the path to a linked library, and that can be the base used for
resource location (not just for the ICU data file(s), but also for the
"runtime" directory, etc.).
JEff
Matt Diephouse
> Now on to actually *trying out* Parrot ... as a former ANSForth Technical Committee
> member, think I'll try the Forth first :-)
Hurm. The Forth in CVS has been somewhat abandoned (though
functional). I've been working on a re-write if you want to check that
out:
http://matt.diephouse.com/software/parrot-forth-0.1.tar.gz
It's not as functional as the Forth in CVS... yet.
You can also look at Parakeet, which is a Forth-like language. There
was a recent discussion about Forth and Parakeet too:
http://xrl.us/du8w (Link to groups.google.com)
Enjoy (Parrot). :-)
--
matt
Dan Sugalski
>Nicholas Clark wrote:
>
>> So I think that deleting the empty directory /usr/local/uplevel for the
>> duration of the build should solve your problem.
>
>Removed the dir, finished the build, recreated the dir, and make
>install worked.
>
>Now on to actually *trying out* Parrot ... as a former ANSForth
>Technical Committee
>member, think I'll try the Forth first :-)
Uh, oh, all my Forth implementation sins are going to get exposed. :)
I really should go finish it at some point, though I've been hoping
that parakeet or Matt's reimplementation would get done before I
rounded up the tuits for it.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jack J. Woehr
> Enjoy (Parrot). :-)
I did ... briefly!
[17:33:55 jax@mitra:/usr/local/src/PerlSource/parrot_stuff/forth]$ parrot forth.pir
Parrot Forth 0.1
Type `bye` to exit
> words
over 2* spaces */ swap 2dup rot drop depth cr 0sp - space words / emit . dup ?dup + * pick .s bye -rot
> Segmentation Fault (core dumped)
[17:34:00 jax@mitra:/usr/local/src/PerlSource/parrot_stuff/forth]$
Jack J. Woehr
I thought the --prefix argument was like in Gnu configs, but I find
that --prefix=/usr/local/uplevel results in a lot of Parrot stuff being dumped unceremoniously
into that very directory instead of only in subdirectories. This install process should either
restrict itself to subdirs or be more finely grained.
Matt Diephouse
> Matt Diephouse wrote:
> > Enjoy (Parrot). :-)
>
> I did ... briefly!
[ . . . ]
> > Segmentation Fault (core dumped)
Oops. I forgot to mention that some recent (big) changes to Parrot has
been causing my Forth implementation some trouble. I filed a bug
report earlier today; hopefully it'll get fixed soon (generally
doesn't take long).
--
matt
Jack J. Woehr
> Oops. I forgot to mention that some recent (big) changes to Parrot has
> been causing my Forth implementation some trouble. I filed a bug
> report earlier today; hopefully it'll get fixed soon (generally
> doesn't take long).
No problem ... my interest is tangential at the moment, though I look forward
to Perl 6. Thanks again Matt and Leopold and Dan and everyone for all your
help. Now I'm off to see how far I get with Perl 6 itself.
Leopold Toetsch
> I thought the --prefix argument was like in Gnu configs, but I find
> that --prefix=/usr/local/uplevel results in a lot of Parrot stuff
> being dumped unceremoniously into that very directory instead of only
> in subdirectories. This install process should either restrict itself
> to subdirs or be more finely grained.
Well, the default is /usr/local/parrot-$(VERSION) but you are of course
right.
leo