Packing man page znc.1.gz...
Building source file version.cpp...
Packing man page znc-buildmod.1.gz...
Building core object main...
Building core object ZNCString...
Building module adminlog...
Building core object Csocket...
In file included from ./../include/znc/Buffer.h:22:0,
from ./../include/znc/IRCNetwork.h:22,
from adminlog.cpp:19:
./../include/znc/Message.h:108:10: error: expected initializer before '&' token
./../include/znc/Message.h:114:22: error: expected initializer before '&' token
./../include/znc/Message.h:120:16: error: expected initializer before '&' token
./../include/znc/Message.h:124:28: error: expected initializer before '&' token
In file included from ./include/znc/Client.h:23:0,
from ./include/znc/znc.h:21,
from src/main.cpp:17:
./include/znc/Message.h:108:10: error: expected initializer before '&' token
./include/znc/Message.h:114:22: error: expected initializer before '&' token
./include/znc/Message.h:120:16: error: expected initializer before '&' token
./include/znc/Message.h:124:28: error: expected initializer before '&' token
make[1]: *** [adminlog.o] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....
make: *** [src/main.o] Error 1
```
Packing man page znc.1.gz...
Building source file version.cpp...
Packing man page znc-buildmod.1.gz...
Building core object main...
Building core object ZNCString...
Building module adminlog...
Building core object Csocket...
In file included from ./../include/znc/Buffer.h:22:0,
from ./../include/znc/IRCNetwork.h:22,
from adminlog.cpp:19:
./../include/znc/Message.h:108:10: error: expected initializer before '&' token
./../include/znc/Message.h:114:22: error: expected initializer before '&' token
./../include/znc/Message.h:120:16: error: expected initializer before '&' token
./../include/znc/Message.h:124:28: error: expected initializer before '&' token
In file included from ./include/znc/Client.h:23:0,
from ./include/znc/znc.h:21,
from src/main.cpp:17:
./include/znc/Message.h:108:10: error: expected initializer before '&' token
./include/znc/Message.h:114:22: error: expected initializer before '&' token
./include/znc/Message.h:120:16: error: expected initializer before '&' token
./include/znc/Message.h:124:28: error: expected initializer before '&' token
make[1]: *** [adminlog.o] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....
make: *** [src/main.o] Error 1
```
<!-- github-sync-id:118471286 -->
Ah.
GCC supports ref-qualifiers since 4.8.1, https://gcc.gnu.org/projects/cxx0x.html
Probably it's time to bump compiler requirements even more, while still staying inside C++11...
Ah.
GCC supports ref-qualifiers since 4.8.1, https://gcc.gnu.org/projects/cxx0x.html
Probably it's time to bump compiler requirements even more, while still staying inside C++11...
<!-- github-comment-id:159065586 -->
@TheReverend403 This also further breaks Ubuntu on older versions that still have support (though there are workarounds for that) - 1.6 introduced such a standards change, so I don't think "introducing changes that break older distributions" is an issue here (it's why older distorts are old/obsolete after a while).
This would likely break building on older distributions other than Debian too, though I don't see how that should be a factor in the ZNC upstream project here for making changes and bumping build reqs upward.
@TheReverend403 This also further breaks Ubuntu on older versions that still have support (though there are workarounds for that) - 1.6 introduced such a standards change, so I don't think "introducing changes that break older distributions" is an issue here (it's why older distorts are old/obsolete after a while).
This would likely break building on older distributions other than Debian too, though I don't see how that should be a factor in the ZNC upstream project here for making changes and bumping build reqs upward.
<!-- github-comment-id:159248391 -->
2015-11-24 12:05 GMT+00:00 Thomas Ward notifications@github.com:
@TheReverend403 https://github.com/TheReverend403 This also further
breaks Ubuntu on older versions that still have support (though there are
workarounds for that) - 1.6 introduced such a standards change, so I don't
think "introducing changes that break older distributions" is an issue here
(it's why older distorts are old/obsolete after a while).
It depends on how old they are. It's not feasible to support something very
very old, but it's good to support something not so old. There is some
compromise anyway.
This would likely break building on older distributions other than Debian
too, though I don't see how that should be a factor in the ZNC upstream
project here for making changes and bumping build reqs upward.
Some incompatibilities are easy to workaround by ifdef or reduced features
(this breakage can be worked around). But such ifdefs increase maintenance
burden, so again, need some compromise.
What distros are broken by this?
Debian 7 is EOL at Feb 2016, according to Wikipedia; I think it's fine to
have ifdef in place until Feb 2016.
2015-11-24 12:05 GMT+00:00 Thomas Ward notifications@github.com:
> @TheReverend403 https://github.com/TheReverend403 This also further
> breaks Ubuntu on older versions that still have support (though there are
> workarounds for that) - 1.6 introduced such a standards change, so I don't
> think "introducing changes that break older distributions" is an issue here
> (it's why older distorts are old/obsolete after a while).
It depends on how old they are. It's not feasible to support something very
very old, but it's good to support something not so old. There is some
compromise anyway.
> This would likely break building on older distributions other than Debian
> too, though I don't see how that should be a factor in the ZNC upstream
> project here for making changes and bumping build reqs upward.
Some incompatibilities are easy to workaround by ifdef or reduced features
(this breakage can be worked around). But such ifdefs increase maintenance
burden, so again, need some compromise.
What distros are broken by this?
Debian 7 is EOL at Feb 2016, according to Wikipedia; I think it's fine to
have ifdef in place until Feb 2016.
—
> Reply to this email directly or view it on GitHub
> https://github.com/znc/znc/issues/1189#issuecomment-159248391.
<!-- github-comment-id:159298661 -->
@DarthGandalf In Ubuntu, only Ubuntu Precise is broken, though the workaround I use for the PPA builds which uses a newer gcc/g++ toolchain in those builds can be updated and applied for that (such that there is no actual fail to build, though the further we go forward in version for the g++ version, the less reliable the Ubuntu PPAs are on the older release). No other Ubuntu releases are impacted by the increase in C++/g++ version requirements (4.8 is already in Ubuntu Trusty and later).
@DarthGandalf In Ubuntu, only Ubuntu Precise is broken, though the workaround I use for the PPA builds which uses a newer gcc/g++ toolchain in those builds can be updated and applied for that (such that there is no actual fail to build, though the further we go forward in version for the g++ version, the less reliable the Ubuntu PPAs are on the older release). No other Ubuntu releases are impacted by the increase in C++/g++ version requirements (4.8 is already in Ubuntu Trusty and later).
<!-- github-comment-id:159304119 -->
EPEL 6 (which works with RHEL and CentOS) is broken since the switch to C++11. It'd be nice if I could continue to build ZNC for EPEL6
EPEL 6 (which works with RHEL and CentOS) is broken since the switch to C++11. It'd be nice if I could continue to build ZNC for EPEL6
<!-- github-comment-id:159323051 -->
@teward Ubuntu Precise has 4.6, so broken regardless, unless the right PPA is installed.
@nbebout well, unless there is some way to use C++11 in EPEL, it goes to bucket "very very old" and therefore "infeasible", sorry.
This issue is only about GCC 4.7 vs 4.8.
@teward Ubuntu Precise has 4.6, so broken regardless, unless the right PPA is installed.
@nbebout well, unless there is some way to use C++11 in EPEL, it goes to bucket "very very old" and therefore "infeasible", sorry.
<!-- github-comment-id:159391250 -->
@DarthGandalf True statement, but the only place the correct PPA being installed is done to my knowledge is my one server and the staging PPAs I use for the ZNC builds ;)
@DarthGandalf True statement, but the only place the correct PPA being installed is done to my knowledge is my one server and the staging PPAs I use for the ZNC builds ;)
<!-- github-comment-id:159392978 -->
It also was used on travis, until we upgraded it to 14.04.
End users who want to compile software from source can use it too.
It also was used on travis, until we upgraded it to 14.04.
End users who want to compile software from source can use it too.
<!-- github-comment-id:159395858 -->
This has worked for most of people using CentOS 6 and the ones that it didn't work for weren't enough experienced to use search engine or something... It's also worth noting that the current release of CentOS is 7 and as far as I am aware it works or no one hasn't told me otherwise.
> EPEL 6 (which works with RHEL and CentOS) is broken since the switch to C++11. It'd be nice if I could continue to build ZNC for EPEL6
- http://wiki.znc.in/FAQ#Upgrade_your_compiler._GCC_4.7.2B_and_Clang_3.2.2B_are_known_to_work.
This has worked for most of people using CentOS 6 and the ones that it didn't work for weren't enough experienced to use search engine or something... It's also worth noting that the current release of CentOS is 7 and as far as I am aware it works or no one hasn't told me otherwise.
<!-- github-comment-id:159499451 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ah.
GCC supports ref-qualifiers since 4.8.1, https://gcc.gnu.org/projects/cxx0x.html
Probably it's time to bump compiler requirements even more, while still staying inside C++11...
Doing so would break support for Debian 7, which does not have GCC 4.8 in it's repo.
@TheReverend403 This also further breaks Ubuntu on older versions that still have support (though there are workarounds for that) - 1.6 introduced such a standards change, so I don't think "introducing changes that break older distributions" is an issue here (it's why older distorts are old/obsolete after a while).
This would likely break building on older distributions other than Debian too, though I don't see how that should be a factor in the ZNC upstream project here for making changes and bumping build reqs upward.
2015-11-24 12:05 GMT+00:00 Thomas Ward notifications@github.com:
It depends on how old they are. It's not feasible to support something very
very old, but it's good to support something not so old. There is some
compromise anyway.
Some incompatibilities are easy to workaround by ifdef or reduced features
(this breakage can be worked around). But such ifdefs increase maintenance
burden, so again, need some compromise.
What distros are broken by this?
Debian 7 is EOL at Feb 2016, according to Wikipedia; I think it's fine to
have ifdef in place until Feb 2016.
—
@DarthGandalf In Ubuntu, only Ubuntu Precise is broken, though the workaround I use for the PPA builds which uses a newer gcc/g++ toolchain in those builds can be updated and applied for that (such that there is no actual fail to build, though the further we go forward in version for the g++ version, the less reliable the Ubuntu PPAs are on the older release). No other Ubuntu releases are impacted by the increase in C++/g++ version requirements (4.8 is already in Ubuntu Trusty and later).
EPEL 6 (which works with RHEL and CentOS) is broken since the switch to C++11. It'd be nice if I could continue to build ZNC for EPEL6
This issue is only about GCC 4.7 vs 4.8.
@teward Ubuntu Precise has 4.6, so broken regardless, unless the right PPA is installed.
@nbebout well, unless there is some way to use C++11 in EPEL, it goes to bucket "very very old" and therefore "infeasible", sorry.
@DarthGandalf True statement, but the only place the correct PPA being installed is done to my knowledge is my one server and the staging PPAs I use for the ZNC builds ;)
It also was used on travis, until we upgraded it to 14.04.
End users who want to compile software from source can use it too.
This has worked for most of people using CentOS 6 and the ones that it didn't work for weren't enough experienced to use search engine or something... It's also worth noting that the current release of CentOS is 7 and as far as I am aware it works or no one hasn't told me otherwise.