Summary: | devel/glibmm ustring.h:256:13: error: expected ';' at end of declaration list | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Chris Hutchinson <portmaster> |
Component: | Individual Port(s) | Assignee: | Walter Schwarzenfeld <w.schwarzenfeld> |
Status: | Closed Overcome By Events | ||
Severity: | Affects Many People | CC: | lantw44, w.schwarzenfeld |
Priority: | --- | Flags: | w.schwarzenfeld:
maintainer-feedback?
|
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Chris Hutchinson
2017-12-19 05:28:04 UTC
See also PR 223538, (In reply to Chris Hutchinson from comment #0) 1. GNOME never uses GitHub as its official repo. GitHub repo is just a mirror and the official repo is at https://git.gnome.org/browse/glibmm/. 2. glibmm 2.6 is a very old version. The latest version which is compatible with glibmm-2.4 ABI is glibmm 2.52. FreeBSD ports include glibmm 2.50.1, so I think if the update is really needed, the request should be 'update to 2.52.1', not 'update to 2.6' which is actually a downgrade to a version released more than 10 years ago. I believe the problem is that you don't enable C++11 support in your port. glibmm requires C++11 since version 2.46. Thanks for the quick reply! (In reply to Ting-Wei Lan from comment #2) > (In reply to Chris Hutchinson from comment #0) > > 1. GNOME never uses GitHub as its official repo. GitHub repo is just a > mirror and the official repo is at https://git.gnome.org/browse/glibmm/. Thanks for the correction. > > 2. glibmm 2.6 is a very old version. The latest version which is compatible > with glibmm-2.4 ABI is glibmm 2.52. FreeBSD ports include glibmm 2.50.1, so > I think if the update is really needed, the request should be 'update to > 2.52.1', not 'update to 2.6' which is actually a downgrade to a version > released more than 10 years ago. Well, that sounds about right. But looking at the 2.52.1 source. I see that the same errors will occur. clang expects ~ustring(); but gets ~ustring() noexcept; expects virtual ~Exception(); but gets virtual ~Exception() noexcept = 0; ... > > I believe the problem is that you don't enable C++11 support in your port. > glibmm requires C++11 since version 2.46. That's a good point. Maybe I'm just doing it wrong. But throwing USES= compiler:c++11-lang and CXXFLAGS+= -Wc++11-extensions -Wc++11-long-long didn't get me any closer. Thanks again, for taking the time to respond. --Chris OK there may actually be hope CXXFLAGS+= -std=c++11 -stdlib=libc++ -Wc++11-extensions seems to get me close enough to *hopefully* iron out the rest of the problems. Just thought I'd mention it. --Chris OK while I'm not completely convinced that up(dating|grading) devel/glibmm (and friends) isn't strongly recommended. I *was* finally able to build my port. For anyone else running into similar trouble. The following may get you closer to building your port: add (at least) the following to USES compiler:c++11-lang and (at least) this to USE_CXXSTD c++11 and (at least) the following to CXXFLAGS -stdlib=libc++ -Wc++11-extensions --Chris glibmm 2.56.0 is now released. It uses glibmm-2.4 ABI so it is compatible with previous releases. It looks like I made a mistake on understanding the versioning scheme of glibmm. glibmm 2.52 is not the last ABI-compatible release. Subsequent even-numbered releases are also compatible. Even-numbered stable releases are neither made nor branched from the master branch. There are stable branches used for these stable releases. The latest one is glibmm-2-56 and it was branched from master at version 2.50.0. Odd-numbered unstable releases are made from master branch. They are not compatible with stable releases. This means version 2.55 and 2.56 are not compatible. They are even unrelated to stable releases because they are made from different and possibly diverging branches. Version 2.56.0_1,1 is in the port. Compiles fine. Close here with overcome by events. |