On Thu, 15 Oct 2020, Tobias Burnus wrote:
> Hi Joseph, hi Jakub,
>
> (a) For the driver route:
>
> On 10/15/20 12:22 AM, Joseph Myers wrote:
> > I think it should be somewhere in the expansion of %(link_gcc_c_sequence)
> > (i.e. LINK_GCC_C_SEQUENCE_SPEC, which has various target-specific
> > definitions), since that's what expands to something like -lgcc -lc -lgcc.
> > Maybe after the first -lgcc and before the -lc, since libatomic has
> > references to libc functions.
>
> Lightly tested draft patch attached. (--enable-autolink-libatomic is 'no' by
> default)
I think the configure option should be on by default.
I'd expect only gcc.c to define LINK_LIBATOMIC_SPEC rather than
duplicating it in gnu-user.h.
I'd expect either a default definition of LINK_LIBATOMIC_SPEC to "" when
the configure option is disabled, or else conditionals in the macros that
use LINK_LIBATOMIC_SPEC to avoid them using an undefined macro.
> When trying the patch, one runs into the problem that -latomic
> fails in the target configure for libgomp ("error: C compiler
> cannot create executables"). Any suggestion? (That's on x86_64-gnu-linux.)
Yes, making this change means you need to ensure the build of target
libraries and testcases can find the in-build-tree libatomic (and that
tests can find it at runtime as needed in the shared library case), just
like it already needs to be able to find the in-build-tree libgcc.
In the case of libgcc, the libgcc build process copies the libraries into
the host-side gcc/ object directory. Maybe doing that for libatomic would
be simpler than teaching lots of separate places how to find libatomic in
the build tree (though for any tests that might use shared libatomic at
runtime, it's still necessary to ensure that works for testing GCC).
--
Joseph S. Myers
jos...@codesourcery.com
