This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CFT: [build] Move shlib support to toplevel libgcc


On 08/10/2011 01:14 PM, Rainer Orth wrote:
* At the moment, SHLIB_LINK is used in gcc/Makefile.in and the various
   Make-lang.in fragments to check if the target supports a shared
   libgcc_s.  I've introduced gcc/config/t-slibgcc (from t-slibgcc-dummy)
   for this, which sets SHLIB = true, adding that fragment to all targets
   in config.gcc that do.  There may be a better way to handle this.

Yes, there is no need to use $(shell) in the first place---you can use ifeq/ifneq---and perhaps an AC_DEFINE will be even better. But I agree this is the simplest way to fix it for now.


** AIX:

    Both t-aix43 and t-aix52 SHLIB_* variables now live in
    rs6000/t-slibgcc-aix.  They were identical except that the t-aix52
    variant had been updated for cross-compilation.  I haven't changed
    them to allow use of t-slibgcc, but that could perhaps be done as a
    followup.

No need for that.


** HP-UX:

    After editing the PA and IA-64 HP-UX SHLIB_* variables into a form to
    allow comparison with t-slibgcc, it turned out that the differences
    are actually minimal.  I only needed to introduce INSTALL_SHLIB to
    allow for the install -m 555 of the shared libgcc_s only needed on
    HP-UX.

Very nice.


    BASEVER_c isn't available outside of gcc, so I need to parse $(CC)
    --version output instead.

We could also (later) write an M4 macro to process gcc/BASE-VER and friends, and substitute those into the Makefile.


    While alpha/t-vms already extracted symbol information with objdump
    --syms, ia64/t-vms still used a hardcoded list
    (ia64/vms_symvec_libgcc_s.opt).  Since it has the comment `It would
    be better to auto-generate this file.', I've omitted it, hoping that
    the alpha procedure also works on ia64.  This obviously needs to be
    tested.

Tristan, can you do that?


** Windows:

    While the windows code hasn't been touched apart from the move, the
    various t-* fragments are so interdependent that I could easily have
    made a mistake.

Looks good.


* The test for sjlj exceptions was already (almost) duplicated 3 times
   in libgo (for C), libjava (for C++), and libobjc (for Objective-C).
   I've created just another copy from the libgo variant, but it would be
   better to centralize this.

Please add a comment on top of it, so that we can take care of this later.


* There's another issue I haven't attacked yet: while currently
   libgcc/Makefile.in performs a couple of substitions on SHLIB_*
   variables, this shouldn't be necessary any longer:

	@multilib_dir@			$(MULTIDIR)
         @multilib_flags@		$(CFLAGS) -B./
	@shlib_base_name@		libgcc_s
	@shlib_map_file@		$(mapfile)
	@shlib_objs@			$(objects)
	@shlib_slibdir@			$(shlib_slibdir)
	@shlib_slibdir_qual@		$(MULTIOSSUBDIR)

There should be a better way to handle this.

Indeed, but it can be done later. We can change this:


libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts)
        # @multilib_flags@ is still needed because this may use
        # $(GCC_FOR_TARGET) and $(LIBGCC2_CFLAGS) directly.
        # @multilib_dir@ is not really necessary, but sometimes it has
        # more uses than just a directory name.
        $(mkinstalldirs) $(MULTIDIR)
        $(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \
                @multilib_dir@,$(MULTIDIR),$(subst \
                @shlib_objs@,$(objects),$(subst \
                @shlib_base_name@,libgcc_s,$(subst \
                @shlib_map_file@,$(mapfile),$(subst \
                @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \
                @shlib_slibdir@,$(shlib_slibdir),$(SHLIB_LINK))))))))

to:

DUMMY := $(shell $(mkinstalldirs) $(MULTIDIR))
libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts)

and then change the definitions of SHLIB_LINK to rules for libgcc_s$(SHLIB_EXT). Likewise for other cases.

Could affected OS port/target maintainers please give the patch a try?

The patch is okay after it has been bootstrapped on IA64/VMS and Win32.


Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]