Arnaud Charlet <char...@adacore.com> writes: >> Ok, I see. Perhaps gcc/ada could be disentangled and those files >> exclusively or primarily used for libgnat/libgnarl moved over to libada, >> and referenced from there for the host build? > > That would require some delicate work on AdaCore's side, so wouldn't be > helpful in the short term (rather harmful actually).
I wasn't suggesting this as a short-term project, but given the clutter of gcc/ada might be a good idea longer term. >> > So passing PICFLAG down to the gcc/ada/gcc-interface Makefile and not >> > just via libada/Makefile is indeed important. >> >> This seems to be easy: unless I'm mistaken, it should suffice to just >> call GCC_PICFLAG in gcc/configure.ac and substitute the result in >> gcc/ada/gcc-interface/Makefile.in. What's the best way to test this? > > You can e.g. add some dummy target in the Makefile that will echo > the value of this variable. Sure, I was rather asking how make gnatlib (or whatever) is supposed to be invoked? From gcc/ada, any special needs? >> I've often had serious trouble when I tried to run make >> gnatlib/gnatlib-shared in gcc/ada. > > Apparently "someone" in the past removed too many things from the Makefile > which broke partly this support (probably thinking that with libada/Makefile, > these changes were not needed anymore). We have local changes at AdaCore in > the > Makefile that basically ignores these changes. It would be good to contribute them, perhaps for close scrutiny by a build maintainer. If anything goes wrong in libada during a bootstrap, investigating and manually retrying is currently painful at best. >> OTOH, it seems you're fine with the general approach of only passing >> PICFLAG to build gnatlib, not everything else that happens to reside in >> TARGET_LIBGCC2_CFLAGS? > > I think that would be fine, although I'm not 100% sure. I can't remember > whether we've needed TARGET_LIBGCC2_CFLAGS for other flags on e.g. some > exotic/non mainstream platform in the past, so can't guarantee that this > change > is a good idea. I'd say worth a try, asa long as we're prepared to have a > "plan B" in case this change does break some exotic platforms unexpectedly. I think to correct way to handle this would be in one of the target-specific sections of gcc/ada/gcc-interface/Makefile.in, adding to CFLAGS with a comment describing the need. If we cannot get rid of libada's need for PICFLAG, this blocks the rest of the toplevel libgcc move, which would be unfortunate. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University