From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 58A323858D28; Thu, 16 Dec 2021 12:11:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 58A323858D28 From: "ro at CeBiTec dot Uni-Bielefeld.DE" To: gcc-bugs@gcc.gnu.org Subject: [Bug d/103528] [12 regression] d21 doesn't build on Solaris Date: Thu, 16 Dec 2021 12:11:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: d X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ibuclaw at gdcproject dot org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 12:11:34 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103528 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Iain Buclaw --- > (In reply to Rainer Orth from comment #0) >> * toplevel configure needs to make certain that the bootstrap gdc can co= mpile >> *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 h= ave a >> fully working GNAT or you have none), while the gdc without libphobos= =20 >> 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 lowe= red > into calls of core druntime helper functions. Without a runtime, this se= verely > 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=3Dall 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=3Dall 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 wi= th > 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: $? =3D 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.=