Catch $RPM_OPT_FLAGS and $RPM_LD_FLAGS by default when building as RPM package

[robert-scheck]

Without $RPM_OPT_FLAGS and $RPM_LD_FLAGS per distribution necessary additional compiler flags are not added (e.g. at Fedora).

[davidgfnet]

What is the problem with the std::to_string function if I may ask?

[dequis]

What is the problem with the std::to_string function if I may ask?

#258

Another problem is using the 'master' branch for pull requests, and including unrelated commits, but, whatever.

Another problem is using gcc 4.4.6, which causes a bunch of these problems, but this is probably because it's RHEL 6 which is still very widely used, sooo

[davidgfnet]

Are you guys working together?
Yeah, well if you use gcc 4.4 you are on your own, sorry. Let's move on to C++11 which seems the most reasonable thing to do.

[dequis]

Heh, not really, he just poked me the other day asking if i knew c++ to help him with these bugs (i don't), and i told him that you'd probably take care of it in a few days but ehhhh.

He's the maintainer of the bitlbee package in redhat/fedora (and other ~100 packages). As a maintainer he could probably keep distro-version-specific patches, but it's better to avoid it if possible.

Also note that RHEL 6 has another 5 years left in its support lifecycle, but it's up to you to choose if you want to support it, anyway.

[robert-scheck]

@davidgfnet, I would be really very pleased if we could keep GCC 4.4 compatibility for some time (maybe 2 years?) at least. RHEL/CentOS 6 is still very common, especially when it comes to BitlBee. From a developer view I understand that GCC 4.4 is old, but as of writing the changes to keep the compatibility should hopefully not be that heavy.

[robert-scheck]

@davidgfnet Any chances to keep GCC 4.4 support for at least the limited feature set that BitlBee uses?