On Fri, 2008-07-25 at 09:00 +0200, Arnaud Charlet wrote:
> > 1/ Ada multilib build is enabled unless --disable-multilib is used in
> > configure: this means that the Ada build has more opportunity to fail
> > because of code generation bugs or libada source selection issue, but in
> > this later case it will be a only few lines in gcc/ada/Makefile.in to
> > fix it once reported.
>
> Are you volunteering to make these changes when this will happen, or at least
> provide an easy work around (which does not involve --disable-multilib, since
> people probably want multilibs, at least for non Ada languages) ?
Yes I volunteer. We're in stage1 so we have some time to sort out
reported issues before release.
> > 2/ once built is installed no visible change for users, to use
> > multilib you have to follow directions above.
> >
> > The patch is missing some cleanup, comments, doc update and ChangeLog.
> > With those added and after the big tuple and gcc-interface changes are
> > in is this ok to resubmit and commit? If not what are the blocking
> > issues?
>
> Without seeing the changelog it's hard to comment in details, but I do not
> understand how installation works, and in particular
> why you commented out the 'install-gnatlib' target.
Only libada/Makefile.in install will be invoked for all multilib
by the install machinery so gcc/ada/Makefile.in install cannot
do properly the rts install work anymore, hence the change. The relevant
libada/Makefile.in parts are now:
+install-gnatlib: $(GCC_DIR)/ada/Makefile
+ $(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) \
+ libsubdir="$(libsubdir)" \
+ install-gnatlib
+
# Installation rules.
-install:
+install: install-gnatlib
+ $(MULTIDO) DO=install multi-do # $(MAKE)
I will remove instead of comment out.
> I also do not understand how the selection of the right target run-time files
> is done in this scheme. I guess I need to see the changelog or some other
> explanation for that.
It has to be done with ifeq on $(MULTISUBDIR) in gcc/ada/Makefile.in
for all targets where there are multilib (according to gcc/config/*/t-*)
and the rts sources are not generic. In the x86_64-linux case it was
easy:
+ifeq ($(strip $(filter-out %x86_64 linux%,$(arch) $(osys))),)
+ ifeq ($(strip $(MULTISUBDIR)),/32)
+ arch:=i686
+ endif
+endif
Tactically I can submit the mechanical parts of the patch separately
since it obscures the rest of the patch which is otherwise quite simple:
<<
The patch touches lots of gcc/ada/Makefile.in but hopefully 99% of the
change is mechanical:
1/ replace all use of "rts" by "$(RTSDIR)"
2/ replace all use of "stamp-gnatlib*" by "stamp-gnatlib*-$(RTSDIR)"
Once these changes are in place by setting RTSDIR one can build
multiple Ada rts without conflict from gcc/ada/Makefile.in
>>
I think this will help review and this is useful change on its own,
should I test and submit this first part separately?
Thanks in advance,
Laurent
PS: I did start some review of PAIRS but I could not find the "marte"
runtime sources in SVN:
a-exetim.adb<a-exetim-linux-marte.adb \ ...
Is it a commit oversight?
