https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103528
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #5 from Iain Buclaw <ibuclaw at gdcproject dot org> --- > (In reply to Rainer Orth from comment #0) >> * toplevel configure needs to make certain that the bootstrap gdc can compile >> *and link* some trivial D program. Letting the build proceed otherwise >> leads >> to confusing link errors as seen here. gnat can do away without such a >> test >> because there are no gnat without libgnat configurations (either you have a >> fully working GNAT or you have none), while the gdc without libphobos >> situation is quite common in GCC. > I'm on the side-line with that observation though, gdc without libphobos has > been defaulted in configure.tgt more because I lack the means for testing such > a broad amount of targets (such as non-x86 BSDs). When someone does test it > (powerpc64le-freebsd) the report I get back is usually that it works fine. > > Rather gdc without libphobos is more of an exception, because the compiler > heavily depends on it existing anyway, with many high-level features lowered > into calls of core druntime helper functions. Without a runtime, this > severely > limits what you can do in the language to a strict subset (that might as well > be C). I've never claimed that this configuration is actually useful for D development use. However, before the switch to d21 in D, you could configure gcc with --enable-languages=all even on targets that didn't support libphobos (either because it just wasn't declared as supported in configure.tgt or because it wouldn't compile). The resulting build would produce gdc and d21 and the gdc.* tests would run only those thats that can work without libphobos, most of them actually succeeding. After the switch to the D d21, this no longer works: if you do this on a target that lacks either gdc or libphobos for any reason, the --enable-languages=all configuration would succeed, howeve, the stage1 libphobos build will fail, possibly for seemingly obscure reasons only becoming (sort of) obvious when one inspects $target/libphobos/config.log. I'd call this a regression and it's certainly a bad user experience. To make things worse, there's no --disable-language option, so to avoid this one needs to configure with an explicit list of languages excluding d, which is going to break (or miss a possibly working language) the next time one is added to GCC (gm2 is imminent). I argue that this can be avoided by checking (in toplevel configure) that a trivial D program can be compiled and linked and excluding d from the list if languages if not (or aborting the configure run if absolutely need be). Much less headache for users, I'd say... > To pick a similar example, is this a bug? Or can it be explained away with > documentation? > --- > checking for long long... yes > checking size of long long... configure: error: in `/work/gcc/build/gcc': > configure: error: cannot compute sizeof (long long) > See `config.log' for more details > make[1]: *** [Makefile:4511: configure-gcc] Error 1 > make[1]: Leaving directory '/work/gcc/build' > make: *** [Makefile:985: all] Error 2 > --- > (config.log) > configure:6450: checking size of long long > configure:6455: g++ -o conftest -g conftest.cpp >&5 > /usr/bin/ld: cannot find -lstdc++ > collect2: error: ld returned 1 exit status > configure:6455: $? = 1 > configure: program exited with status 1 > --- But how do you get to such a configuration to begin with? You're certainly taking some special steps to have g++, but no libstc++. This is contrary to the D situation where that config emerges without doing anything special. Similarly for Ada where you either have both gnat and libgnat or neither.
