[perl #31765] Failure related to ncurses
Andy Dougherty
# Please include the string: [perl #31765]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31765 >
With the recent root Makefile patch to build stuff in
runtime/parrot/library, I'm now getting the following failure (split to
avoid long lines)
./parrot -o runtime/parrot/library/ncurses.pbc \
runtime/parrot/library/ncurses.imc
Couldn't load 'runtime/parrot/libncurses': \
ld.so.1: ./parrot: fatal: runtime/parrot/libncurses: \
open failed: No such file or directory
The biggest problem with the message is that it never tells you exactly
*which* file was not found.
In this case, the problem turns out to be the statement in
runtime/parrot/library/ncurses.imc:
loadlib $P1, 'libncurses'
which *assumes* that my 'curses' library is called 'libncurses'. It's
not. On Solaris, for example (and probably on most SVR4-related systems),
it's simply 'libcurses'.
Where and how to fix this is a bit of a problem. Obviously, it's a
Configure.pl issue to figure out which library to use. But beyond that,
it's unclear to me exactly where to put that new information and what to
do with it.
In the runtime/parrot/library/ directory, the string
'libncurses' appears in three different files:
ncurses.declarations:libncurses.so
ncurses.imc:loadlib $P1, 'libncurses'
ncurses.pasm:loadlib P1, 'libncurses'
Changing it in one has no obvious affect on the others. I can't find any
documentation about the .declarations file at all, nor how (or whether)
the .imc and/or .pasm files are generated from the .declarations file.
Are all of them needed? If so, then the .declarations file also needs to
be changed to have a more general suffix instead of just .so.
Or should we just skip it for now as we skip SDL and postgres?
In any case, a better error message would sure help tracking down things
like this.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> The biggest problem with the message is that it never tells you exactly
> *which* file was not found.
Is the error message now more informative?
> In the runtime/parrot/library/ directory, the string
> 'libncurses' appears in three different files:
> ncurses.declarations:libncurses.so
> ncurses.imc:loadlib $P1, 'libncurses'
> ncurses.pasm:loadlib P1, 'libncurses'
> Changing it in one has no obvious affect on the others. I can't find any
> documentation about the .declarations file at all, nor how (or whether)
> the .imc and/or .pasm files are generated from the .declarations file.
Dan?
leo
Dan Sugalski
The pasm file is old and can go. The declarations file was used to
generate the pasm by one of the utilities, and it was then turned
into the imc file.
We should probably fix things up so the imc file is generated by the
declarations file automatically.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Andy Dougherty
> Andy Dougherty <parrotbug...@parrotcode.org> wrote:
>
> > The biggest problem with the message is that it never tells you exactly
> > *which* file was not found.
>
> Is the error message now more informative?
I can't tell at the moment. The build never got that far, but instead
failed with
string_set_data_directory: ICU data files not found(apparently) for directory [/home/doughera/parrot/blib/lib/icu/2.6.1]
Parrot is apparently looking under $prefix for the icu data
directories, but parrot hasn't been installed yet. I vaguely recall something
about the icu directory changed recently -- I'll go back and
read up on exactly what changed, see if I can get parrot to work
again, try re-building, and then check on the ncurses error message.
--
Andy Dougherty doug...@lafayette.edu
Andy Dougherty
> On Fri, 8 Oct 2004, Leopold Toetsch via RT wrote:
>
> > Andy Dougherty <parrotbug...@parrotcode.org> wrote:
> >
> > > The biggest problem with the message is that it never tells you exactly
> > > *which* file was not found.
> >
> > Is the error message now more informative?
Without the patch below, I just get a core dump. With the patch below,
yes, it's more informative.
--- parrot-current/src/dynext.c Fri Oct 8 13:41:12 2004
+++ parrot-andy/src/dynext.c Tue Oct 12 12:42:53 2004
@@ -217,7 +217,7 @@
}
err = Parrot_dlerror();
fprintf(stderr, "Couldn't load '%s': %s\n",
- full_name, err ? err : "unknown reason");
+ file_name, err ? err : "unknown reason");
return NULL;
}
--
Andy Dougherty doug...@lafayette.edu
Nicholas Clark
> On Tue, 12 Oct 2004, Andy Dougherty wrote:
>
> > On Fri, 8 Oct 2004, Leopold Toetsch via RT wrote:
> >
> > > Andy Dougherty <parrotbug...@parrotcode.org> wrote:
> > >
> > > > The biggest problem with the message is that it never tells you exactly
> > > > *which* file was not found.
> > >
> > > Is the error message now more informative?
>
> Without the patch below, I just get a core dump. With the patch below,
> yes, it's more informative.
Indeed :-)
> --- parrot-current/src/dynext.c Fri Oct 8 13:41:12 2004
> +++ parrot-andy/src/dynext.c Tue Oct 12 12:42:53 2004
> @@ -217,7 +217,7 @@
> }
> err = Parrot_dlerror();
> fprintf(stderr, "Couldn't load '%s': %s\n",
> - full_name, err ? err : "unknown reason");
> + file_name, err ? err : "unknown reason");
Would it be better as
full_name ? full_name : file_name
? Assuming that full_name when non-NULL has even more information.
Nicholas Clark
Leopold Toetsch
> full_name ? full_name : file_name
Probably not. If full_name wasn't found in dynext, it's NULL. At the
point of the error message, C<file_name> is used.
Changed like above.
> Nicholas Clark
leo