[Bug ada/19489] gnat tools not buildable cross

["joel at oarcorp dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joel at oarcorp dot com  2005-02-09 12:44 -------
Subject: Re:  gnat tools not buildable cross

neroden at twcny dot rr dot com wrote:
> ------- Additional Comments From neroden at twcny dot rr dot com  2005-02-09 07:13 -------
> Subject: Re:  gnat tools not buildable cross
> 
> joel at oarcorp dot com wrote:
> 
>>------- Additional Comments From joel at oarcorp dot com  2005-02-08 19:16 -------
>>Subject: Re:  gnat tools not buildable cross
>>
>>neroden at gcc dot gnu dot org wrote:
>>
>>
>>>------- Additional Comments From neroden at gcc dot gnu dot org  2005-02-08 18:30 -------
>>>
>>>
>>>
>>>>Is a fix likely to get into 4.0? 
>>>
>>>Yes, the hackish fix is in.  I hope to get the cleaner fix in, but who knows. 
>>>
>>>
>>>
>>>
>>>>FYI Once I am able to build, the next issue is that the Ada libraries 
>>>>do not look into newlib's headers and do not have a way to let a 
>>>>target add specific include directories.  See gcc/config/t-rtems for 
>>>>the OS specific newlib include directory we need.  With that resolved, 
>>>>I think it could build in a single pass. 
>>>
>>>I wouldn't want to touch this until substantially more of the branch went in, 
>>>so that's probably a 4.1 issue. 
>>
>>
>>I need to get to test this first but I think the mistake in the 
>>gcc/ada/Makefile.in is actually quite simple.  It has this:
>>
>>
>>GNATLIBCFLAGS_FOR_C = $(GNATLIBCFLAGS) $(TARGET_LIBGCC2_CFLAGS) 
>>-fexceptions \
>>         -DIN_RTS
>>
>>
>>$(TARGET_LIBGCC2_CFLAGS) is not sufficient to find all the newlib
>>headers.  But the gcc/Makefile.in also uses $(LIBGCC2_INCLUDES) which is
>>target specific when compiling libgcc2.  LIBGCC2_INCLUDES is primarily 
>>set by RTEMS, VxWorks, and Cygwin.
>>
>>What do you think?
> 
> 
> Hmm.  You could be right.  :-)
> 
> The trouble is that there's several layers of Makefiles and Makefile 
> fragments and configures and configure fragments taking bits from each 
> other, and so it's not as absolutely trivial to get LIBGCC2_INCLUDES in 
> the right places cleanly -- without misapplying it in cross cases -- as 
> it ought to be.  This, of course, is what my cleanups are designed to 
> fix; it *should* be trivial to get it in the right places.  :-)

I played with this overnight and the variable missing in ada/Makefile.in 
is  FLAGS_FOR_TARGET.  It shoudl be included in GNATLIBCFLAGS_FOR_C and 
I can't seem to get it from the top level configure all the way down.

Do you have any idea how to get it down that far?

--joel




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489