| Message ID | 4964955d-4de1-618c-de41-835ca19f9932@ubuntu.com |
|---|---|
| State | New |
| Headers | show |
Hi Matthias, >> Here's what I tested. This requires a boehm-gc version 7.0 or later >> (having the >> header files in a gc subdirectory). Depending on your available library, it >> only builds the GC enabled library for the default multilib library, and just >> skips over building the non-default multilib variants (assuming that most >> people >> won't have a libgc for that installed). The --enable-objc-gc option is not this assumption may not hold, though: in Solaris 11+ where libgc is bundled, both 32 and 64-bit libs are present, as always. I'd also claim that for multilib testing in general, it's bad to test different multilibs with different configurations, so I'd rather have people doing multilib testing obtain all variants of libgc. Rainer
> On 6 Oct 2016, at 17:42, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > >>> Here's what I tested. This requires a boehm-gc version 7.0 or later >>> (having the >>> header files in a gc subdirectory). Depending on your available library, it >>> only builds the GC enabled library for the default multilib library, and just >>> skips over building the non-default multilib variants (assuming that most >>> people >>> won't have a libgc for that installed). The --enable-objc-gc option is not > > this assumption may not hold, though: in Solaris 11+ where libgc is > bundled, both 32 and 64-bit libs are present, as always. I'd also claim > that for multilib testing in general, it's bad to test different > multilibs with different configurations, so I'd rather have people doing > multilib testing obtain all variants of libgc. likewise on Darwin, people may well build “fat” libraries, and I also would encourage testing of m32/m64, Iain
On 06.10.2016 18:46, Iain Sandoe wrote: > >> On 6 Oct 2016, at 17:42, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >> > >>>> Here's what I tested. This requires a boehm-gc version 7.0 or later >>>> (having the >>>> header files in a gc subdirectory). Depending on your available library, it >>>> only builds the GC enabled library for the default multilib library, and just >>>> skips over building the non-default multilib variants (assuming that most >>>> people >>>> won't have a libgc for that installed). The --enable-objc-gc option is not >> >> this assumption may not hold, though: in Solaris 11+ where libgc is >> bundled, both 32 and 64-bit libs are present, as always. I'd also claim >> that for multilib testing in general, it's bad to test different >> multilibs with different configurations, so I'd rather have people doing >> multilib testing obtain all variants of libgc. > > likewise on Darwin, people may well build “fat” libraries, and I also would encourage testing of m32/m64, so you both prefer to hard-fail if any of the libgc variants needed for the multilibs is missing? Maybe force this behaviour with --enable-objc-gc=yes, and skip those which are not available with -enable-objc-gc=auto? Matthias
Hi Matthias, >>> this assumption may not hold, though: in Solaris 11+ where libgc is >>> bundled, both 32 and 64-bit libs are present, as always. I'd also claim >>> that for multilib testing in general, it's bad to test different >>> multilibs with different configurations, so I'd rather have people doing >>> multilib testing obtain all variants of libgc. >> >> likewise on Darwin, people may well build “fat” libraries, and I also >> would encourage testing of m32/m64, > > so you both prefer to hard-fail if any of the libgc variants needed for the > multilibs is missing? Maybe force this behaviour with --enable-objc-gc=yes, and > skip those which are not available with -enable-objc-gc=auto? I wouldn't hard-fail, but completely disable objc-gc with an appropriate warning. The Objective-C maintainers may have other preferences, though. Rainer
> On 6 Oct 2016, at 17:56, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > >>>> this assumption may not hold, though: in Solaris 11+ where libgc is >>>> bundled, both 32 and 64-bit libs are present, as always. I'd also claim >>>> that for multilib testing in general, it's bad to test different >>>> multilibs with different configurations, so I'd rather have people doing >>>> multilib testing obtain all variants of libgc. >>> >>> likewise on Darwin, people may well build “fat” libraries, and I also >>> would encourage testing of m32/m64, >> >> so you both prefer to hard-fail if any of the libgc variants needed for the >> multilibs is missing? Maybe force this behaviour with --enable-objc-gc=yes, and >> skip those which are not available with -enable-objc-gc=auto? > > I wouldn't hard-fail, but completely disable objc-gc with an appropriate > warning. The Objective-C maintainers may have other preferences, though. that seems a reasonable strategy to me too (disable that capability when the library is not present) - I suspect that most people do not usually build with GC support anyway (but no firm statistics to back the hunch). Iain
On Oct 6, 2016, at 9:56 AM, Rainer Orth <ro@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. 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.
On 06.10.2016 20:00, Mike Stump wrote: > On Oct 6, 2016, at 9:56 AM, Rainer Orth <ro@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
> On 7 Oct 2016, at 00:58, Matthias Klose <doko@ubuntu.com> wrote: > > On 06.10.2016 20:00, Mike Stump wrote: >> On Oct 6, 2016, at 9:56 AM, Rainer Orth <ro@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. > >> 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
On 07.10.2016 10:30, Iain Sandoe wrote: > >> On 7 Oct 2016, at 00:58, Matthias Klose <doko@ubuntu.com> wrote: >> >> On 06.10.2016 20:00, Mike Stump wrote: >>> On Oct 6, 2016, at 9:56 AM, Rainer Orth <ro@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 >
> On 10 Oct 2016, at 05:03, Matthias Klose <doko@ubuntu.com> wrote: > > On 07.10.2016 10:30, Iain Sandoe wrote: >> >>> On 7 Oct 2016, at 00:58, Matthias Klose <doko@ubuntu.com> wrote: >>> >>> On 06.10.2016 20:00, Mike Stump wrote: >>>> On Oct 6, 2016, at 9:56 AM, Rainer Orth <ro@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 >> >
2016-10-06 Matthias Klose <doko@ubuntu.com> * boehm-gc: Remove * Makefile.def: Remove boehm-gc dependencies. * Makefile.in: Regenerate. * configure.ac: Include pkg.m4, check for bdw-gc pkg-config module. * configure: Regenerate. config/ 2016-10-06 Matthias Klose <doko@ubuntu.com> * pkg.m4: New file. libobjc/ 2016-10-06 Matthias Klose <doko@ubuntu.com> * configure.ac: Include pkg.m4, use bdw-gc pkg-config module. * configure: Regenerate. * Makefile.in: Remove boehm-gc include, use system boehm-gc library. * gc.c, memory.c, objects.c: Include system boehm-gc headers. Index: Makefile.def =================================================================== --- Makefile.def (revision 240829) +++ Makefile.def (working copy) @@ -166,7 +166,6 @@ target_modules = { module= libgloss; no_check=true; }; target_modules = { module= libffi; no_install=true; }; target_modules = { module= zlib; }; -target_modules = { module= boehm-gc; }; target_modules = { module= rda; }; target_modules = { module= libada; }; target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; }; @@ -544,7 +543,6 @@ // a dependency on libgcc for native targets to configure. lang_env_dependencies = { module=libiberty; no_c=true; }; -dependencies = { module=configure-target-boehm-gc; on=all-target-libstdc++-v3; }; dependencies = { module=configure-target-fastjar; on=configure-target-zlib; }; dependencies = { module=all-target-fastjar; on=all-target-zlib; }; dependencies = { module=configure-target-libgo; on=configure-target-libffi; }; @@ -552,8 +550,6 @@ dependencies = { module=all-target-libgo; on=all-target-libbacktrace; }; dependencies = { module=all-target-libgo; on=all-target-libffi; }; dependencies = { module=all-target-libgo; on=all-target-libatomic; }; -dependencies = { module=configure-target-libobjc; on=configure-target-boehm-gc; }; -dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; }; dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; }; dependencies = { module=configure-target-liboffloadmic; on=configure-target-libgomp; }; dependencies = { module=configure-target-libsanitizer; on=all-target-libstdc++-v3; }; Index: config/pkg.m4 =================================================================== --- config/pkg.m4 (nonexistent) +++ config/pkg.m4 (working copy) @@ -0,0 +1,275 @@ +dnl pkg.m4 - Macros to locate and utilise pkg-config. -*- Autoconf -*- +dnl serial 11 (pkg-config-0.29) +dnl +dnl Copyright © 2004 Scott James Remnant <scott@netsplit.com>. +dnl Copyright © 2012-2015 Dan Nicholson <dbn.lists@gmail.com> +dnl +dnl This program is free software; you can redistribute it and/or modify +dnl it under the terms of the GNU General Public License as published by +dnl the Free Software Foundation; either version 2 of the License, or +dnl (at your option) any later version. +dnl +dnl This program is distributed in the hope that it will be useful, but +dnl WITHOUT ANY WARRANTY; without even the implied warranty of +dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +dnl General Public License for more details. +dnl +dnl You should have received a copy of the GNU General Public License +dnl along with this program; if not, write to the Free Software +dnl Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA +dnl 02111-1307, USA. +dnl +dnl As a special exception to the GNU General Public License, if you +dnl distribute this file as part of a program that contains a +dnl configuration script generated by Autoconf, you may include it under +dnl the same distribution terms that you use for the rest of that +dnl program. + +dnl PKG_PREREQ(MIN-VERSION) +dnl ----------------------- +dnl Since: 0.29 +dnl +dnl Verify that the version of the pkg-config macros are at least +dnl MIN-VERSION. Unlike PKG_PROG_PKG_CONFIG, which checks the user's +dnl installed version of pkg-config, this checks the developer's version +dnl of pkg.m4 when generating configure. +dnl +dnl To ensure that this macro is defined, also add: +dnl m4_ifndef([PKG_PREREQ], +dnl [m4_fatal([must install pkg-config 0.29 or later before running autoconf/autogen])]) +dnl +dnl See the "Since" comment for each macro you use to see what version +dnl of the macros you require. +m4_defun([PKG_PREREQ], +[m4_define([PKG_MACROS_VERSION], [0.29]) +m4_if(m4_version_compare(PKG_MACROS_VERSION, [$1]), -1, + [m4_fatal([pkg.m4 version $1 or higher is required but ]PKG_MACROS_VERSION[ found])]) +])dnl PKG_PREREQ + +dnl PKG_PROG_PKG_CONFIG([MIN-VERSION]) +dnl ---------------------------------- +dnl Since: 0.16 +dnl +dnl Search for the pkg-config tool and set the PKG_CONFIG variable to +dnl first found in the path. Checks that the version of pkg-config found +dnl is at least MIN-VERSION. If MIN-VERSION is not specified, 0.9.0 is +dnl used since that's the first version where most current features of +dnl pkg-config existed. +AC_DEFUN([PKG_PROG_PKG_CONFIG], +[m4_pattern_forbid([^_?PKG_[A-Z_]+$]) +m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$]) +m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$]) +AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility]) +AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path]) +AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search path]) + +if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then + AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) +fi +if test -n "$PKG_CONFIG"; then + _pkg_min_version=m4_default([$1], [0.9.0]) + AC_MSG_CHECKING([pkg-config is at least version $_pkg_min_version]) + if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then + AC_MSG_RESULT([yes]) + else + AC_MSG_RESULT([no]) + PKG_CONFIG="" + fi +fi[]dnl +])dnl PKG_PROG_PKG_CONFIG + +dnl PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) +dnl ------------------------------------------------------------------- +dnl Since: 0.18 +dnl +dnl Check to see whether a particular set of modules exists. Similar to +dnl PKG_CHECK_MODULES(), but does not set variables or print errors. +dnl +dnl Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG]) +dnl only at the first occurence in configure.ac, so if the first place +dnl it's called might be skipped (such as if it is within an "if", you +dnl have to call PKG_CHECK_EXISTS manually +AC_DEFUN([PKG_CHECK_EXISTS], +[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl +if test -n "$PKG_CONFIG" && \ + AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$1"]); then + m4_default([$2], [:]) +m4_ifvaln([$3], [else + $3])dnl +fi]) + +dnl _PKG_CONFIG([VARIABLE], [COMMAND], [MODULES]) +dnl --------------------------------------------- +dnl Internal wrapper calling pkg-config via PKG_CONFIG and setting +dnl pkg_failed based on the result. +m4_define([_PKG_CONFIG], +[if test -n "$$1"; then + pkg_cv_[]$1="$$1" + elif test -n "$PKG_CONFIG"; then + PKG_CHECK_EXISTS([$3], + [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null` + test "x$?" != "x0" && pkg_failed=yes ], + [pkg_failed=yes]) + else + pkg_failed=untried +fi[]dnl +])dnl _PKG_CONFIG + +dnl _PKG_SHORT_ERRORS_SUPPORTED +dnl --------------------------- +dnl Internal check to see if pkg-config supports short errors. +AC_DEFUN([_PKG_SHORT_ERRORS_SUPPORTED], +[AC_REQUIRE([PKG_PROG_PKG_CONFIG]) +if $PKG_CONFIG --atleast-pkgconfig-version 0.20; then + _pkg_short_errors_supported=yes +else + _pkg_short_errors_supported=no +fi[]dnl +])dnl _PKG_SHORT_ERRORS_SUPPORTED + + +dnl PKG_CHECK_MODULES(VARIABLE-PREFIX, MODULES, [ACTION-IF-FOUND], +dnl [ACTION-IF-NOT-FOUND]) +dnl -------------------------------------------------------------- +dnl Since: 0.4.0 +dnl +dnl Note that if there is a possibility the first call to +dnl PKG_CHECK_MODULES might not happen, you should be sure to include an +dnl explicit call to PKG_PROG_PKG_CONFIG in your configure.ac +AC_DEFUN([PKG_CHECK_MODULES], +[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl +AC_ARG_VAR([$1][_CFLAGS], [C compiler flags for $1, overriding pkg-config])dnl +AC_ARG_VAR([$1][_LIBS], [linker flags for $1, overriding pkg-config])dnl + +pkg_failed=no +AC_MSG_CHECKING([for $1]) + +_PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) +_PKG_CONFIG([$1][_LIBS], [libs], [$2]) + +m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS +and $1[]_LIBS to avoid the need to call pkg-config. +See the pkg-config man page for more details.]) + +if test $pkg_failed = yes; then + AC_MSG_RESULT([no]) + _PKG_SHORT_ERRORS_SUPPORTED + if test $_pkg_short_errors_supported = yes; then + $1[]_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors --cflags --libs "$2" 2>&1` + else + $1[]_PKG_ERRORS=`$PKG_CONFIG --print-errors --cflags --libs "$2" 2>&1` + fi + # Put the nasty error message in config.log where it belongs + echo "$$1[]_PKG_ERRORS" >&AS_MESSAGE_LOG_FD + + m4_default([$4], [AC_MSG_ERROR( +[Package requirements ($2) were not met: + +$$1_PKG_ERRORS + +Consider adjusting the PKG_CONFIG_PATH environment variable if you +installed software in a non-standard prefix. + +_PKG_TEXT])[]dnl + ]) +elif test $pkg_failed = untried; then + AC_MSG_RESULT([no]) + m4_default([$4], [AC_MSG_FAILURE( +[The pkg-config script could not be found or is too old. Make sure it +is in your PATH or set the PKG_CONFIG environment variable to the full +path to pkg-config. + +_PKG_TEXT + +To get pkg-config, see <http://pkg-config.freedesktop.org/>.])[]dnl + ]) +else + $1[]_CFLAGS=$pkg_cv_[]$1[]_CFLAGS + $1[]_LIBS=$pkg_cv_[]$1[]_LIBS + AC_MSG_RESULT([yes]) + $3 +fi[]dnl +])dnl PKG_CHECK_MODULES + + +dnl PKG_CHECK_MODULES_STATIC(VARIABLE-PREFIX, MODULES, [ACTION-IF-FOUND], +dnl [ACTION-IF-NOT-FOUND]) +dnl --------------------------------------------------------------------- +dnl Since: 0.29 +dnl +dnl Checks for existence of MODULES and gathers its build flags with +dnl static libraries enabled. Sets VARIABLE-PREFIX_CFLAGS from --cflags +dnl and VARIABLE-PREFIX_LIBS from --libs. +dnl +dnl Note that if there is a possibility the first call to +dnl PKG_CHECK_MODULES_STATIC might not happen, you should be sure to +dnl include an explicit call to PKG_PROG_PKG_CONFIG in your +dnl configure.ac. +AC_DEFUN([PKG_CHECK_MODULES_STATIC], +[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl +_save_PKG_CONFIG=$PKG_CONFIG +PKG_CONFIG="$PKG_CONFIG --static" +PKG_CHECK_MODULES($@) +PKG_CONFIG=$_save_PKG_CONFIG[]dnl +])dnl PKG_CHECK_MODULES_STATIC + + +dnl PKG_INSTALLDIR([DIRECTORY]) +dnl ------------------------- +dnl Since: 0.27 +dnl +dnl Substitutes the variable pkgconfigdir as the location where a module +dnl should install pkg-config .pc files. By default the directory is +dnl $libdir/pkgconfig, but the default can be changed by passing +dnl DIRECTORY. The user can override through the --with-pkgconfigdir +dnl parameter. +AC_DEFUN([PKG_INSTALLDIR], +[m4_pushdef([pkg_default], [m4_default([$1], ['${libdir}/pkgconfig'])]) +m4_pushdef([pkg_description], + [pkg-config installation directory @<:@]pkg_default[@:>@]) +AC_ARG_WITH([pkgconfigdir], + [AS_HELP_STRING([--with-pkgconfigdir], pkg_description)],, + [with_pkgconfigdir=]pkg_default) +AC_SUBST([pkgconfigdir], [$with_pkgconfigdir]) +m4_popdef([pkg_default]) +m4_popdef([pkg_description]) +])dnl PKG_INSTALLDIR + + +dnl PKG_NOARCH_INSTALLDIR([DIRECTORY]) +dnl -------------------------------- +dnl Since: 0.27 +dnl +dnl Substitutes the variable noarch_pkgconfigdir as the location where a +dnl module should install arch-independent pkg-config .pc files. By +dnl default the directory is $datadir/pkgconfig, but the default can be +dnl changed by passing DIRECTORY. The user can override through the +dnl --with-noarch-pkgconfigdir parameter. +AC_DEFUN([PKG_NOARCH_INSTALLDIR], +[m4_pushdef([pkg_default], [m4_default([$1], ['${datadir}/pkgconfig'])]) +m4_pushdef([pkg_description], + [pkg-config arch-independent installation directory @<:@]pkg_default[@:>@]) +AC_ARG_WITH([noarch-pkgconfigdir], + [AS_HELP_STRING([--with-noarch-pkgconfigdir], pkg_description)],, + [with_noarch_pkgconfigdir=]pkg_default) +AC_SUBST([noarch_pkgconfigdir], [$with_noarch_pkgconfigdir]) +m4_popdef([pkg_default]) +m4_popdef([pkg_description]) +])dnl PKG_NOARCH_INSTALLDIR + + +dnl PKG_CHECK_VAR(VARIABLE, MODULE, CONFIG-VARIABLE, +dnl [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) +dnl ------------------------------------------- +dnl Since: 0.28 +dnl +dnl Retrieves the value of the pkg-config variable for the given module. +AC_DEFUN([PKG_CHECK_VAR], +[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl +AC_ARG_VAR([$1], [value of $3 for $2, overriding pkg-config])dnl + +_PKG_CONFIG([$1], [variable="][$3]["], [$2]) +AS_VAR_COPY([$1], [pkg_cv_][$1]) + +AS_VAR_IF([$1], [""], [$5], [$4])dnl +])dnl PKG_CHECK_VAR Index: configure.ac =================================================================== --- configure.ac (revision 240829) +++ configure.ac (working copy) @@ -29,6 +29,7 @@ m4_include([ltversion.m4]) m4_include([lt~obsolete.m4]) m4_include([config/isl.m4]) +m4_include([config/pkg.m4]) AC_INIT(move-if-change) AC_PREREQ(2.64) @@ -161,7 +162,6 @@ target-libssp \ target-libquadmath \ target-libgfortran \ - target-boehm-gc \ target-libffi \ target-libobjc \ target-libada \ @@ -2060,23 +2060,15 @@ [AS_HELP_STRING([--enable-objc-gc], [enable use of Boehm's garbage collector with the GNU Objective-C runtime])], -[case ,${enable_languages},:${enable_objc_gc}:${noconfigdirs} in - *,objc,*:*:yes:*target-boehm-gc*) - AC_MSG_ERROR([Boehm's garbage collector was requested yet not supported in this configuration]) +[AC_MSG_CHECKING([for Boehm's garbage collector]) + case ,${enable_languages},:${enable_objc_gc} in + *,objc,*:yes) + PKG_CHECK_EXISTS(bdw-gc, + AC_MSG_RESULT([found]), + AC_MSG_ERROR([bdw-gc pkg-config module not found])) ;; esac]) -# Make sure we only build Boehm's garbage collector if required. -case ,${enable_languages},:${enable_objc_gc} in - *,objc,*:yes) - # Keep target-boehm-gc if requested for Objective-C. - ;; - *) - # Otherwise remove target-boehm-gc. - noconfigdirs="$noconfigdirs target-boehm-gc" - ;; -esac - # Disable libcilkrts, libitm, libsanitizer, libvtv, liboffloadmic if we're not building C++ case ,${enable_languages}, in *,c++,*) Index: libobjc/Makefile.in =================================================================== --- libobjc/Makefile.in (revision 240829) +++ libobjc/Makefile.in (working copy) @@ -47,8 +47,6 @@ top_builddir = . --include ../boehm-gc/threads.mk - libdir = $(exec_prefix)/lib libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(gcc_version) @@ -95,7 +93,7 @@ OBJC_GCFLAGS=@OBJC_GCFLAGS@ OBJC_BOEHM_GC=@OBJC_BOEHM_GC@ OBJC_BOEHM_GC_INCLUDES=@OBJC_BOEHM_GC_INCLUDES@ -OBJC_BOEHM_GC_LIBS=../boehm-gc/libgcjgc_convenience.la $(thread_libs_and_flags) +OBJC_BOEHM_GC_LIBS=@OBJC_BOEHM_GC_LIBS@ INCLUDES = -I$(srcdir)/$(MULTISRCTOP)../gcc \ -I$(srcdir)/$(MULTISRCTOP)../gcc/config \ Index: libobjc/configure.ac =================================================================== --- libobjc/configure.ac (revision 240829) +++ libobjc/configure.ac (working copy) @@ -18,6 +18,8 @@ #along with GCC; see the file COPYING3. If not see #<http://www.gnu.org/licenses/>. +m4_include([../config/pkg.m4]) + AC_PREREQ(2.64) AC_INIT(package-unused, version-unused,, libobjc) AC_CONFIG_SRCDIR([objc/objc.h]) @@ -57,26 +59,6 @@ [version_specific_libs=no]) AC_MSG_RESULT($version_specific_libs) -AC_ARG_ENABLE(objc-gc, -[ --enable-objc-gc enable the use of Boehm's garbage collector with - the GNU Objective-C runtime.], -[case $enable_objc_gc in - no) - OBJC_GCFLAGS='' - OBJC_BOEHM_GC='' - OBJC_BOEHM_GC_INCLUDES='' - ;; - *) - OBJC_GCFLAGS='-DOBJC_WITH_GC=1' - OBJC_BOEHM_GC='libobjc_gc$(libsuffix).la' - OBJC_BOEHM_GC_INCLUDES='-I$(top_srcdir)/../boehm-gc/include -I../boehm-gc/include' - ;; -esac], -[OBJC_GCFLAGS=''; OBJC_BOEHM_GC=''; OBJC_BOEHM_GC_INCLUDES='']) -AC_SUBST(OBJC_GCFLAGS) -AC_SUBST(OBJC_BOEHM_GC) -AC_SUBST(OBJC_BOEHM_GC_INCLUDES) - # ----------- # Directories # ----------- @@ -214,6 +196,38 @@ gt_BITFIELD_TYPE_MATTERS +# ----------- +# boehm-gc +# ----------- + +AC_ARG_ENABLE(objc-gc, +[ --enable-objc-gc enable the use of Boehm's garbage collector with + the GNU Objective-C runtime.], +[case $enable_objc_gc in + no) + OBJC_GCFLAGS='' + OBJC_BOEHM_GC='' + OBJC_BOEHM_GC_INCLUDES='' + OBJC_BOEHM_GC_LIBS='' + ;; + *) + PKG_CHECK_MODULES(BDW_GC, bdw-gc >= 7) + AC_CHECK_LIB(gc, GC_init, [ + OBJC_GCFLAGS='-DOBJC_WITH_GC=1' + OBJC_BOEHM_GC='libobjc_gc$(libsuffix).la' + OBJC_BOEHM_GC_INCLUDES=$BDW_GC_CFLAGS + OBJC_BOEHM_GC_LIBS=$BDW_GC_LIBS + ],[ + : dnl no libgc for multilib variants available + ]) + ;; +esac], +[OBJC_GCFLAGS=''; OBJC_BOEHM_GC=''; OBJC_BOEHM_GC_LIBS=''; OBJC_BOEHM_GC_INCLUDES='']) +AC_SUBST(OBJC_GCFLAGS) +AC_SUBST(OBJC_BOEHM_GC) +AC_SUBST(OBJC_BOEHM_GC_INCLUDES) +AC_SUBST(OBJC_BOEHM_GC_LIBS) + # ------ # Output # ------ Index: libobjc/gc.c =================================================================== --- libobjc/gc.c (revision 240829) +++ libobjc/gc.c (working copy) @@ -36,7 +36,7 @@ #include "objc/runtime.h" #include "objc-private/module-abi-8.h" -#include <gc.h> +#include <gc/gc.h> #include <limits.h> /* gc_typed.h uses the following but doesn't declare them */ @@ -44,7 +44,7 @@ typedef GC_signed_word signed_word; #define BITS_PER_WORD (CHAR_BIT * sizeof (word)) -#include <gc_typed.h> +#include <gc/gc_typed.h> /* The following functions set up in `mask` the corresponding pointers. The offset is incremented with the size of the type. */ Index: libobjc/memory.c =================================================================== --- libobjc/memory.c (revision 240829) +++ libobjc/memory.c (working copy) @@ -41,7 +41,7 @@ #include "objc/runtime.h" #if OBJC_WITH_GC -#include <gc.h> +#include <gc/gc.h> void * objc_malloc (size_t size) Index: libobjc/objects.c =================================================================== --- libobjc/objects.c (revision 240829) +++ libobjc/objects.c (working copy) @@ -31,8 +31,8 @@ #include <string.h> /* For memcpy() */ #if OBJC_WITH_GC -# include <gc.h> -# include <gc_typed.h> +# include <gc/gc.h> +# include <gc/gc_typed.h> #endif /* FIXME: The semantics of extraBytes are not really clear. */