On Wed, Aug 07, 2013 at 02:29:35PM +0200, Dominique Dhumieres wrote:
> Revision 201555 breaks boostrap on x86_64-apple-darwin10:
>
> ...
> Checking multilib configuration for libvtv...
> make all-recursive
> Making all in testsuite
> /bin/sh: line 0: cd: testsuite: No such file or directory
> make[4]: *** [all-recursive] Error 1
> make[3]: *** [all] Error 2
> make[2]: *** [all-stage1-target-libvtv] Error 2
> make[1]: *** [stage1-bubble] Error 2
> make: *** [all] Error 2
>
> According to
>
> * configure.ac: Add target-libvtv to target_libraries; disable libvtv
> on non-linux systems; add target-libvtv to noconfigdirs; add
> libsupc++/.libs to C++ library search paths.
>
> libvtv should not be built on darwin, but in config.log I see
>
> ...
> configure:3222: checking for libvtv support
> configure:3232: result: yes
> ...
Same on powerpc*-linux.
In looking at it briefly, I see several things wrong with the way libvtv is
configured. Here is the guts of libvtv/configure.tgt:
case "${target}" in
x86_64-*-linux* | i?86-*-linux*)
VTV_SUPPORTED=yes
;;
powerpc*-*-linux*)
;;
sparc*-*-linux*)
;;
arm*-*-linux*)
;;
x86_64-*-darwin[1]* | i?86-*-darwin[1]*)
VTV_SUPPORTED=no
;;
*)
UNSUPPORTED=1
;;
esac
In the two places that use this script (top level configure, and configure
within libvtv), they both run the .tgt script with . ./<file>,. However, they
do no explicitly clear the UNSUPPORTED variable. So perhaps you might have
some other script within the configure process use UNSUPPORTED, and it would
not get built for the system that supports it.
Then there is the problem that the two callers use different shell variables to
check whether the library is supported or not. I tend to think the top level
configure should be changed to look at VTV_SUPPORTED and not UNSUPPORTED, and
that only the systems that it is know to work on should set the variable to
yes.
I.e.
case "${target}" in
x86_64-*-linux* | i?86-*-linux*)
VTV_SUPPORTED=yes
unset UNSUPPORTED
;;
*)
VTV_SUPPORTED=no
UNSUPPORTED=1
;;
esac
(remove the UNSUPPORTED lines if we change the top level configure).
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
