> On 10 Oct 2016, at 05:03, Matthias Klose <d...@ubuntu.com> wrote: > > On 07.10.2016 10:30, Iain Sandoe wrote: >> >>> On 7 Oct 2016, at 00:58, Matthias Klose <d...@ubuntu.com> wrote: >>> >>> On 06.10.2016 20:00, Mike Stump wrote: >>>> On Oct 6, 2016, at 9:56 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> >>>> wrote: >>>>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate >>>>> warning. The Objective-C maintainers may have other preferences, though. >>> >>> I think I can't do that in the top level make file very well (currently I >>> only >>> have the pkg-config check there for an early failure, but that check doesn't >>> tell me if the library is present for all multilib variants). And I can't >>> check >>> for multilibs because I don't know if the bootstrap compiler is multilib >>> aware. >> >> hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s >> the configurer’s responsibility to provide a path with appropriate >> headers/libs for the multi-lib configuration being attempted. > > I don't understand what you are proposing here.
given that: auto-detection of the capabilities could be quite difficult (or, in the general case, unachievable) for the reasons you gave. the chosen target libraries might be in a non-standard place. making it an explicit requirement to point to them, and to ensure that the versions/multi-libs provided are suitable, (by putting —with-target-boehm-gc=/path/to/suitable/) would mean that the dependent configury (for objc-gc) could be just conditional upon the presence of the "with-target-boehm-gc”. I suppose that one could make "—with-target-boehm-gc” (no attached path) declare that the library (and requisite mult-lib versions) will be found in the sysroot without any additional work. The point here was to simplify the dependent configury so that it only needs to test something that the configuring user specifies (i.e. if they specify objc-gc, then they need also to specify the place that the gc lib can be found). >>>> gcc historically is fairly weak at complex configurations. I need the 32 >>>> bit libraries to support -m32, but, those libraries might not be present, >>>> but do I build all the rest of my libraries, and if i do, do I test them >>>> once build, but what is other dependent external libraries are missing. >>>> Do I turn off the multilib, or do I not? >>>> >>>> I used to manage some of this by passing in configure flags to control >>>> multilibbing based upon what libraries were install and then run testing >>>> based upon that. Of course, that's all external to gcc proper. Doesn't >>>> really make gcc any easier to configure and build or advance gcc. >>>> >>>> We could smell the system at configure time, and turn on and off multilib >>>> variants and things like objc gc. Target specific, but I think it helps to >>>> ponder this in a target independent way. This can then turn on and off >>>> objc gc support directly. To get it on, one would need to install the >>>> needed libraries, and reconfigure and rebuild gcc. I think I might like >>>> that the best. Has a nice easy of use about it, and then everything gcc >>>> does is rather sane (no funny build errors when a needed library isn't >>>> present). >>>> >>>> >>>> So, I think, if I understand what you propose, I'm fine with that. >>> >>> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac >>> with >>> a hard error message and leave it to the user to correctly configure GCC? >>> That >>> would rely on the compiler to find the library in a system wide multilib >>> aware >>> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32). Is this the case >>> for >>> Solaris and Darwin? >> >> for Darwin, it’s not a default install (but then neither are the host deps >> such as gmp & friends) - so the toolchain builder on Darwin already needs to >> make some provisions outside the system. It’s just that the only target >> provisions to date have been the sysroot (we haven’t yet made use of add-on >> target libs). >> >>> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu >>> where multilib is the default (but objc-gc is not). >>> >>> Looking back at libjava, I think everybody disabled multilibs for libjava, >>> because nobody had a complete gtk2 stack for multilibs, however that was a >>> complete subdir, not just a certain configuration in that subdir. Looking >>> back >>> at libffi and separate released libffi's I first built multilib'ed libffi >>> libraries from the libffi source for Debian/Ubuntu, then dropped these >>> because >>> they were not used, and until today GCC internal and external libffi are >>> hopelessly out of sync, so you couldn't use an external libffi to build >>> libjava. >> >> Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally >> libjava (and libffi, gc) were generally built and tested (by those who cared >> to do it) as multilibs [the default]. >>> >>> In the past I looked at updating boehm-gc to recent sources but never >>> finished >>> because libjava relied on internals. Afaics this is not the case for >>> objc-gc, >>> so maybe you could update boehm-gc. But I don't want to go this road myself >>> … >> >> .. and I don’t have cycles to volunteer to try this at present either. >> Iain >> >> >>> >>> Matthias >> >
