I hit this on an arm device but I can't see how it won't affect all arches. slim fails due to a trivial syntax error: /var/tmp/portage/x11-misc/slim-1.3.4/work/slim-1.3.4/Ck.cpp: In member function 'const char* Ck::Session::get_x11_device(const string&)': /var/tmp/portage/x11-misc/slim-1.3.4/work/slim-1.3.4/Ck.cpp:94:5: error: 'snprintf' is not a member of 'std' /var/tmp/portage/x11-misc/slim-1.3.4/work/slim-1.3.4/Ck.cpp:94:5: note: suggested alternative: /usr/include/bits/stdio2.h:62:1: note: 'snprintf' make[2]: *** [CMakeFiles/slim.dir/Ck.cpp.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-misc/slim-1.3.4/work/slim-1.3.4_build' make[1]: *** [CMakeFiles/slim.dir/all] Error 2 make[1]: Leaving directory `/var/tmp/portage/x11-misc/slim-1.3.4/work/slim-1.3.4_build' make: *** [all] Error 2 The problem is on line 94 of slim-1.3.4/Ck.cpp. They have std::snprintf but snprintf isn't in std! Just change that line from std::snprintf(device, 32, "/dev/tty%ld", vt); to snprintf(device, 32, "/dev/tty%ld", vt); and slim is a happy camper! Reproducible: Always
For whatever reason, ARM is not C++98 compatible in that cdstio does not provide std::snprintf ... I'm proposing to fix this by changing the call from std::snprintf to std::sprintf , but I need confirmation that std::sprintf exists on arm (i don't trust the arm devel doc i came across earlier while googling). (Fortunately, the buffer that std::snprintf is writing to will always be bigger than the maximum-possible value of the string being written, wnich makes this a trivial change)
+ 05 Oct 2012; Ian Stakenvicius <axs@gentoo.org> slim-1.3.4-r1.ebuild, + +files/slim-1.3.4-arm.patch: + swapped snprintf for sprintf to support arm's broken C++98 (bug 430502) +
Confirmed that this fixes it. Wouldn't a better, albeit harder fix be to fix ARM C++98?
Yes, it would. However, since I expect that this isn't going to happen any time soon (if ever), I figured it would be better to work around the issue rather than wait for compliance. Especially since the workaround doesn't invalidate arches that are fully C++98 compliant.
(In reply to comment #4) > Yes, it would. However, since I expect that this isn't going to happen any > time soon (if ever), I figured it would be better to work around the issue > rather than wait for compliance. Especially since the workaround doesn't > invalidate arches that are fully C++98 compliant. Fair enough.
