This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Unreviewed^3 libgcc patches
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- Cc: gcc-patches at gcc dot gnu dot org, Paolo Bonzini <bonzini at gnu dot org>
- Date: Tue, 25 Oct 2011 15:35:08 +0000 (UTC)
- Subject: Re: Unreviewed^3 libgcc patches
- References: <ydd8vo9cvw0.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
On Tue, 25 Oct 2011, Rainer Orth wrote:
> CFT: [build] Move crtstuff support to toplevel libgcc
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01273.html
OK, updated for changes to GCC since this was posted (at least, for my
change to make i[34567]86-*-elf* and x86_64-*-elf* use i386/t-crtstuff),
in the absence of build system, libgcc or target maintainer objections
within 24 hours. Removing the unused files you identified is also OK on
the same basis.
As a followup it would be good to change the code in
libgcc/config/sparc/t-linux64 that tests for a particular name of a
multilib directory; the preferred way of doing that sort of thing with
toplevel libgcc is to have a configure test determining whether the
particular multilib being built is actually 32-bit or 64-bit and select
the t-* files used on that basis (as is done for some x86/x86_64
configuration).
> CFT: [build] Move libgcc1 to toplevel libgcc
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01274.html
OK on the same basis as the previous patch.
> CFT: [build] Move libgcc2 to toplevel libgcc
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01275.html
OK on the same basis as the previous patch.
> Another one in the series are also pending AFAICS:
>
> CFT: [build] Move shlib support to toplevel libgcc
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00915.html
>
> has been approved modulo VMS/IA64 and Win32 testing. Tristan has
> indicated to go ahead for the VMS side, but I haven't received any Win32
> feedback.
OK on the same basis as the previous patch. Add PR translation/45116 to
the log since removing vms_symvec_libgcc_s.opt fixes that PR.
Regarding the better approach for DRIVER_DEFINES, Tom's old automatic
dependency changes did:
+ifneq ($(SHLIB_LINK),)
+ifeq (@enable_shared@,yes)
+DRIVER_SHLIB = -DENABLE_SHARED_LIBGCC
+else
+DRIVER_SHLIB =
+endif
+else
+DRIVER_SHLIB =
+endif
Avoiding DRIVER_DEFINES containing `test ...` code that requires special
rules for building driver files is definitely desirable, because you can
then just do
CFLAGS-gcc.o += $(DRIVER_DEFINES)
gcc.o: <existing list of dependencies>
and eliminate the special compilation rule; likewise for other drivers.
--
Joseph S. Myers
joseph@codesourcery.com