From: Eric R. K. <ekr...@ba...> - 2005-02-25 13:01:43
|
Rob Pollock wrote: > Using these options to configure didn't work... still got errors from build > process trying to "use" objects that aren't defined!!! > > I passed these options to the top level of ./configure. I tried to > configure from > within the libstdc++ directory (which is the configure script that > these options apply to, i.e. --disable-libstdcxx-pch and > --disable-c-mbchar) and got "could not find > install.sh in ../../ [etc.] errors". These options aren't needed for normal builds. > It seems the configure scripts in the lower level directories are > called by make in > the top level directory. Maybe make never passes the options down to the lower > levels (./gcc ./libstdc++ ./i686-mingw32 etc) The way the GCC build process works is that the top-level 'configure' simply configures building for the top level of the (GCC) source tree. When 'make' is run, the 'configure-host-*' targets are executed to configure the appropriate subdirectories for the host (which for GCC are gcc, intl, and libiberty). When those are built, the 'configure-target-*' targets are executed to configure other things, like runtime libraries, for the target. In GCC's case, this would be libstdc++-v3, libf77, libffi, libjava, ... (though in my case, I use --enable-languages=c,c++ and this the only target-specific dependency compiled is libstdc++-v3). libiberty is also rebuilt for the target as well. > Do you think cross-compiling under cygwin is a better way to go?? > (could be the ONLY way to go...) No (not for Windows 98, at least--things are even worse with Cygwin as far as the fork errors). At this point, it looks like something is causing libstdc++-v3 configure not to find a suitable wchar.h. I'm willing to bet fork failures during the wchar.h (header or function) checks are to blame. Eric |