>> I had to solve one rts source issue though: >> gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of >> bits for a word (64 and 32 respectively), I changed them both to be >> completely the same and use GNAT defined Standard'Word_Size attribute. >> >> - Word_Size : constant := 64; >> - Memory_Size : constant := 2 ** 64; >> + Word_Size : constant := Standard'Word_Size; >> + Memory_Size : constant := 2 ** Word_Size; >> >> The same change will have to be done on other 32/64 bits Ada targets. I >> don't know if this change has adverse effect on GNAT build in some >> situations. > > I think this is worthwhile on its own, before the build patch goes in.
Not clear to me actually. The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is. Also, this points to a real flaw in the approach, since e.g. in case of little/big endian multilibs, similar issue would arise. And, system.ads is only the tip of the iceberg: if you do not get system.ads right, it means that potentially a complete wrong set of sources will be used to build the run-time, since there can be an arbitrary number of target dependent units as defined by LIBGNAT_PAIRS, and indeed, looking at the target pairs for x86 and x86-64, these are quite different, so we need to find a mechanism to properly select the right pair when using multilib. > It looks good to me, though I'll defer to Arnaud and other adacore people. It seems that a branch would be more appropriate for this kind of work, since there's a long way to go before getting in reasonable shape. Also, it's not clear how using $(RTS) for building gnattools will work properly. >> [EMAIL PROTECTED]:~/tmp$ gnatmake -f -g >> -aO/home/guerby/build-mlib7/gcc/ada/rts32 -m32 p There's an existing mechanism in gnatmake which is the use of the --RTS switch, so ideally it would be great to match multilib install into --RTS=xxx compatible dirs, and also have -xxx (e.g. -32 or -64) imply --RTS=xxx. Arno
