This is the mail archive of the gcc@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: [Ada] multilib patch take three


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?


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