[PATCH] PR ada/42254, avoid providing multiple copies of object files to link of GNAT tools

Simon Wright simon@pushface.org
Thu Jan 28 22:52:00 GMT 2010


On 28 Jan 2010, at 07:46, Arnaud Charlet wrote:

>> New strategy: in Darwin only, arrange that common-tools are built using 
>> -nostdlib and a new temporary ada/tools/libgnatc.a which contains only 
>> the C-derived objects from the RTS. This means that the binder will call 
>> in the required Ada-derived objects from the RTS and will fnd the C 
>> objects in the library; and that the RTS directory itself remains untouched.
>> 
>> There are 2 new variables NOSTDLIB and LIBGNATC and I only set them 
>> in the "ifeq ($(strip $(filter-out darwin%,$(osys))),)" section. You may want 
>> the names to be more specific (TOOLS_NOSTDLIB) and/or to be set 
>> explicitly to empty (NOSTDLIB=) at the top?
> 
> That's better, although I think you could reuse TOOLS_LIBS instead of
> defining and using LIBGNATC everywhere.

I define it once (twice, if I default it to empty at the top) and use it only in 
common-tools (I think I should use it in gnatmake-re, gnatlink-re too - 
yes, I should!).

> e.g. in the darwin section use something like:
> 
>  TOOLS_LIBS=$(TOOLS_LIBS) libgnatc$(arext)

The problem I see with that is that TOOLS_LIBS is used elsewhere - 
specifically in the targets ../../gnatmake$(exeext), ../../gnatlink$(exeext). 
These two use the gnatbind -C option and ignore the object file/option 
list, instead using GNATMAKE_OBJS for the local files, TOOLS_LIBS, 
and LIBGNAT for the RTS files. So we'd be back where we started from. 
Also, not clear where to put the dependency that causes libgnatc$(arext) 
to be built.

> This would make the change simpler/lighter for non darwin platforms

If it can be done (I will try) it would be simpler, but since my current 
proposal requires no change at all for other platforms (something I was 
trying hard to avoid) I don't see how it would be lighter for them?

> Changing NOSTDLIB to TOOLS_NOSTDLIB also seems like a good idea.

OK (and I'll set it to empty at the top).



More information about the Gcc-patches mailing list