Joerg Sonnenberger <joerg%bec.de@localhost> writes: > On Thu, Dec 28, 2017 at 08:34:05PM -0500, Greg Troxel wrote: >> >> So, with no other comments: >> >> I propose to adjust glibmm to have GCC_REQD as 4.9 instead of 4.8. >> >> on/after 1700Z on 12/28. >> >> This is icky, because it does mean programs that build with 4.8 may >> link against glibmm which built with 4.9. >> >> However, it seems that 4.8 and 4.9 are pretty much ABI compatible (even >> though in general this is unsound), we don't have a general solution on >> this branch, and firefox does this too. > > Firefox is a leaf package for most common uses. This is not. If the main > program is picking up libstdc++ from base first, glibmm will be using > the old version and simply fail when hitting the regex code. Indeed, the link fails in gtkmm early on. Yes, the non-leafiness is why I am very reluctant to dig into this. But, we have lot of packages not building on netbsd-7. Apparently the new release glibmm decided to depend on 4.9. As a hacky approach, I not only put GCC_REQD+=4.9 in glibmm's Makefile but also the bl3, to force packages that link against it to 4.9. I realize this is unsound, as it doesn't force packages that link against those to use 4.9. But, with this, gnome-system-monitor builds, which means atkmm, pangomm, and gtkmm also build. This should not change behavior with clang, or with gcc >=4.9. All of this will break on systems with gcc <=4.8. So even if there is a lot of trouble in other things, it seems we are better off. All of this points even more strongly to getting gcc version selection actually fixed next quarter. This illustrates a difficult case, since I think we'd like to believe that gcc 4.8 in netbsd-7 is good enough in general. But it's seeming increasingly like it isn't, given how upstreams are depending on >4.8. So what do people think? Is it in the best interest of pkgsrc users (presumably on netbsd-7, or other systems with gcc 4.8, since systems with a pre-4.8 compiler are going to have many more issues) to apply this patch? My inclination is to hold my nose and apply it, but not to get into adding GCC_REQD on other things that break. Index: Makefile =================================================================== RCS file: /cvsroot/pkgsrc/devel/glibmm/Makefile,v retrieving revision 1.75 diff -u -p -r1.75 Makefile --- Makefile 11 Dec 2017 13:37:43 -0000 1.75 +++ Makefile 29 Dec 2017 16:48:52 -0000 @@ -10,7 +10,9 @@ HOMEPAGE= https://www.gtkmm.org/ COMMENT= C++ bindings for glib LICENSE= gnu-gpl-v2 AND gnu-lgpl-v2.1 -GCC_REQD+= 4.8 +# With 4.8, one gets the following: +# error: no matching function for call to 'regex_replace(const char*&, std::regex, const char [3])' +GCC_REQD+= 4.9 USE_LANGUAGES= c c++11 USE_LIBTOOL= yes USE_PKGLOCALEDIR= yes Index: buildlink3.mk =================================================================== RCS file: /cvsroot/pkgsrc/devel/glibmm/buildlink3.mk,v retrieving revision 1.15 diff -u -p -r1.15 buildlink3.mk --- buildlink3.mk 15 Sep 2012 10:04:10 -0000 1.15 +++ buildlink3.mk 29 Dec 2017 16:48:52 -0000 @@ -5,6 +5,11 @@ BUILDLINK_TREE+= glibmm .if !defined(GLIBMM_BUILDLINK3_MK) GLIBMM_BUILDLINK3_MK:= +# It is necessary to use the same compiler to link against libmm as it +# was built with. This is hacky, but enables at least +# gnome-system-monitor to build. +GCC_REQD+= 4.9 + BUILDLINK_API_DEPENDS.glibmm+= glibmm>=2.24.2 BUILDLINK_ABI_DEPENDS.glibmm+= glibmm>=2.32.1nb1 BUILDLINK_PKGSRCDIR.glibmm?= ../../devel/glibmm
Attachment:
signature.asc
Description: PGP signature