On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote:
> Sam James <s...@gentoo.org> writes:
>
> > Richard Biener <richard.guent...@gmail.com> writes:
> >
> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek <ja...@redhat.com> wrote:
> >>>
> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote:
> >>> > That's one option, but maybe it's better the other way round: instead of
> >>> > excluding known-bad targets, restrict cobol to known-good ones
> >>> > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead.
> >>> >
> >>> > I've been using the following for this (should be retested for safety).
> >>>
> >>> I admit I don't really know what works and what doesn't out of the box
> >>> now,
> >>> but your patch looks reasonable to me for 15 branch.
> >>>
> >>> Richard, Robert and/or James, do you agree?
> >>
> >> I agree to restrict =all to enable cobol only for known-good platform
> >> triples.
> >> But IIRC that's what libgcobol configure.tgt does - IIRC intent was to
> >> allow
> >> a cobol build with explicit 'cobol' included even when configure.tgt claims
> >> unsupported? So why's *-*solaris now included in =all?
> >>
> >> I'm a bit confused, I thought we had =all restricted already.
> >
> > Think we may be missing some wiring.
> >
> > # Always enable COBOL for --enable-languages=*cobol*
> > # Otherwise, enable COBOL only for known architectures
> > case ,${enable_languages}, in
> > [...]
> > *)
> > case "${target}" in
> > *-*-darwin*)
> > unsupported_languages="$unsupported_languages cobol"
> > ;;
> > x86_64-*-*|aarch64-*-*)
> > ;;
> > *-*-*)
> > unsupported_languages="$unsupported_languages cobol"
> > ;;
> > esac
> > [... ditto ${host} ...]
> >
> > We don't seem to ever add cobol to unsupported_languages if we added
> > target-libgcobol to noconfigdirs.
> >
> > The earlier check for libgcobol being supported does match other runtime
> > libraries but the only other *language-specific* runtime library it
> > matches is libphobos, where D supports a minimal build without that, so
> > it doesn't cater for this.
>
> so, untested simple:
>
> --- a/configure.ac
> +++ b/configure.ac
> @@ -768,6 +768,7 @@ if test -d ${srcdir}/libgcobol; then
> then
> AC_MSG_RESULT([no])
> noconfigdirs="$noconfigdirs target-libgcobol"
> + unsupported_languages="$unsupported_languages cobol"
> else
> AC_MSG_RESULT([yes])
> fi
>
> may do it for now. It still allows forcing libgcobol build with
> --enable-libgcobol. But if doing --enable-languages=cobol, you'd need
> --enable-libgcobol as well (but no idea if we really have tested cobol
> w/o libgcobol at all yet, or what).
I think we don't do this for any other language, do we?
Sure, if one only configures a library and does not enable the language,
the library is quite useless, and if one only configures the language and
the library is not configured, one can only compile code written in that
language but can't link it nor run it. E.g. for i686-linux (no multilib)
libgcobol is not UNSUPPORTED at the toplevel and so --enable-languages=all,cobol
at least we still build the FE but libgcobol is configured but doesn't build
anything.
So, the unsupported_languages="$unsupported_languages cobol" should IMHO be
more about on which triplets it is known not to build the FE or have similar
major issues with it.
And to be honest, i686-linux is one of them, my patch to avoid depending on
size_t being unsigned long int is not in, so there will be at least many
warnings.
So the previous patch made more sense to me.
Jakub
