ZNC 0b9c7f7 fails to build from fresh clone on Debian 7.9 #642

Closed
opened 2026-10-05 04:35:43 +02:00 by adam · 10 comments
Owner
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 -->
adam closed this issue 2026-10-05 04:35:43 +02:00
Author
Owner

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 -->
Author
Owner

Doing so would break support for Debian 7, which does not have GCC 4.8 in it's repo.

Doing so would break support for Debian 7, which does not have GCC 4.8 in it's repo. <!-- github-comment-id:159110279 -->
Author
Owner

@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 -->
Author
Owner

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.

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 -->
Author
Owner

@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 -->
Author
Owner

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 -->
Author
Owner

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.

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 -->
Author
Owner

@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 -->
Author
Owner

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 -->
Author
Owner

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 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 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#642