http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-11-30
22:03:43 UTC ---
(In reply to comment #10)
> (In reply to comment #6)
> > Created attachment 28779 [details]
> > Patch to use libbacktrace
>
> I have to apply the following patch on your patch in order to be able to
> compile it. ("MULTIBUILDTOP" is empty here and the library is not in
> "/libbacktrace".)
>
> --- libgfortran-backtrace-pr54572.diff.orig 2012-11-27 10:09:13 +0100
> +++ libgfortran-backtrace-pr54572.diff 2012-11-27 10:12:05 +0100
> @@ -51 +51 @@ index abc23cd..dd325bd 100644
> -+ -I$(MULTIBUILDTOP)/../libbacktrace \
> ++ -I$(MULTIBUILDTOP)../libbacktrace \
Good point, fixed. Also the previous line had the same issue, fixed that as
well.
>
>
>
> Additionally, I wonder whether one should have:
>
> --- a/Makefile.def
> +++ b/Makefile.def
> languages = { language=fortran; gcc-check-target=check-fortran;
> lib-check-target=check-target-libquadmath;
> + lib-check-target=check-target-libbacktrace;
> lib-check-target=check-target-libgfortran; };
> languages = { language=java; gcc-check-target=check-java;
>
>
>
>
> And in the same file, I wonder which of the following two is correct:
>
> +dependencies = { module=all-target-libgfortran; on=all-target-libbacktrace;
> };
>
> or
>
> +dependencies = { module=configure-target-libgfortran;
> on=all-target-libbacktrace; };
I modeled this after how the go frontend does it. The idea, AFAICS, is that
libbacktrace is always built as a hard dependency on libgfortran, however, if
libbacktrace doesn't support the target, BACKTRACE_SUPPORTED is set to 0 and a
dummy implementation is provided. That is, we can always unconditionally rely
on libbacktrace being present. This is different from e.g. libquadmath which
may or may not be available on the target, and can be explicitly
enabled/disabled at configure time etc.
