On Aug 11, 2011, at 1:52 PM, Paolo Bonzini wrote: > 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?
Ok for ia64/vms as there are currently other build issue with ia64/vms that I have to fix. I will fix that later too. Tristan. > >> ** 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
