On Sun, Jul 30, 2006 at 05:51:39AM -0700, go moko wrote:
> 
>  I found
> that I can test easily the bash built with the command
> "grep foo <(ls)": if it returns no error, then the
> bash is good.
> Sadly and very disappointingly, all my tests gave good
> bash. Only the one built initially in /tools/bin was
> bad. So it's not a bison problem, nor a library
> problem, nor a configuration one.
> So I looked at the bash documentation about this type
> of command, which I was not familiar with. It appears
> that it's "process substitution", and among others
> explanations, I read that it's a connection between
> processes by a FIFO or a file in '/dev/fd'. I'm far
> for being expert in bash, so I can't explain best. But
> it suggests me that the problem could be related to
> this, and specially to /dev/fd.

 I've reloaded the boot system onto my ppc64 box, and I
confirm that the patched bash (from temp system) fails
grep foo <(ls)  with
bash: syntax error near unexpected token '('

> I started again from the beginning of the book,
> without omitting any step, and this time, the
> constructed bash give the error (quite logical, but I
> was beginning to ask myself). Pointing all the
> possible impacts leads me to the use of clfs user,
> which has perhaps not sufficient rights to /dev or
> others  directories in the host system. So I tried to
> build again bash, but from root. And this time, bingo,
> the bash was good and can execute the command, and so,
> I expect, the glibc test.
>

 That is scary (building as root on the host system).  I suppose we
could perhaps rebuild bash at the end of the test tools, then use
that version if we had to.

I note that my log from cross-compiling bash showed on about the 35th
line

configure: cross-compiling for powerpc64-unknown-linux-gnu is not supported

which makes me think it might be an artefact of cross-compiling.  I
can build and run bash as a normal user on a finished system and the
test works.

 I'll try using --enable-process-substitution in the temp build, in
case that fixes it.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev

Reply via email to