[Bug d/103528] [12 regression] d21 doesn't build on Solaris

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>]

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.