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. > 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? 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. 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 ... Matthias
