--- Dan Nicholson <[EMAIL PROTECTED]> wrote:
> I'm beginning to think that something is amiss with
> the temporary bash
> build in CLFS. I looked at the bash source in
> bash-3.1/subst.c, and
> there are fallbacks for #!defined HAVE_DEV_FD. In
> other words, the
> process substitution <(list) should work no matter
> what.
>
> Checking my temp bash in /tools/bin again, the build
> log says
>
> [11:50 PM [EMAIL PROTECTED] grep /dev/fd
> /mnt/lfs/jhalfs/logs/039-bash
> checking whether /dev/fd is available... absent
>
> [11:51 PM [EMAIL PROTECTED] /tools/bin/bash -c "echo <(ls)"
> /tmp/sh-np-1154390516
>
> So, the process substitution works despite failing
> that feature test.
> I think that's why we don't see the c++-types
> failure in LFS or DIY.
>
> Did you ever try the workaround `./configure ...
> bash_cv_dev_fd=standard'?
I managed to do some more tests and researches, and I
think I've found what is the problem.
It's a specific cross-compiling issue, no matter what
is the compiler (32/64 bits, from host or from
/cross-tools).
In fact, it's not HAVE_DEV_FD that matters, but
PROCESS_SUBSTITUTION, which is found in several .c
files (as subst.c, mentionned by Dan).
How is it defined?
In configure, it's defined to 1 without test (unless
minimal config, which is not our case):
if test $opt_process_subst = yes; then
cat >>confdefs.h <<\_ACEOF
#define PROCESS_SUBSTITUTION 1
_ACEOF
fi
and there's so a line in config.log:
#define PROCESS_SUBSTITUTION 1
But at the end of config.log, there's another line
which include another file, given with the package
(not modified by configure):
#include "config-bot.h"
And in config-bot.h, there's a test about
PROCESS_SUBSTITUTION:
#if !defined (HAVE_DEV_FD) && defined
(NAMED_PIPES_MISSING)
# undef PROCESS_SUBSTITUTION
#endif
It means that PROCESS_SUBSTITUTION is undefined if
/dev/fd is not found (which is the case when we use an
unprivilegied user, in LFS or in CLFS) and if named
pipes are not present on the system.
So I looked at config.h to see that I've:
#define NAMED_PIPES_MISSING 1
which is explained in config.log by:
configure:22081: checking for presence of named pipes
configure:22087: WARNING: cannot check for named pipes
if cross-compiling -- defaulting to missing
configure:22157: result: missing
and, in configure:
echo "$as_me:$LINENO: checking for presence of named
pipes" >&5
echo $ECHO_N "checking for presence of named pipes...
$ECHO_C" >&6
if test "${bash_cv_sys_named_pipes+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
if test "$cross_compiling" = yes; then
{ echo "$as_me:$LINENO: WARNING: cannot check for
named pipes if cross-compiling -- defaulting to
missing" >&5
echo "$as_me: WARNING: cannot check for named pipes if
cross-compiling -- defaulting to missing" >&2;}
bash_cv_sys_named_pipes=missing
...
The difference between LFS and CLFS is here. If we're
cross-compiling (mean that --build and --host are
different), configure don't check named pipes and so
unactivate the process substitution.
So another solution is to force named pipes by adding
a line in config.cache:
echo "bash_cv_sys_named_pipes=yes" >> config.cache
I hope this is the definitive explanation. Quite a
long search for a single glibc test failure!
G. Moko
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
