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
