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