fifo.cpp:181: error: 'INT_MAX' was not declared in this scope
Created attachment 157627 [details, diff] patch for licq. should fix this issue.
Created attachment 157629 [details, diff] patch. sorry. wrong file... 1-st one was ebuild...
Created attachment 157657 [details, diff] fixed typo.
I guess this bug is a (partial) duplicate of bug #218814, where I posted similar patch. IMHO this bug is related rather to gcc-4.3 than to glibc-2.8.
(In reply to comment #4) > I guess this bug is a (partial) duplicate of bug #218814, where I posted > similar patch. IMHO this bug is related rather to gcc-4.3 than to glibc-2.8. > It seems that it is glibc-related. limits.h is glibc's header and some changes in glibc 2.8 requers that limits.h must be included in source code of apps. Maybe it is partial duplicate, but only partial. Look carefully at patch. It is a bit larger, but it didn't fix automake bugs (that are caused by gcc).
(In reply to comment #5) > It seems that it is glibc-related. limits.h is glibc's header and some changes > in glibc 2.8 requers that limits.h must be included in source code of apps. > Maybe it is partial duplicate, but only partial. Look carefully at patch. It is > a bit larger, but it didn't fix automake bugs (that are caused by gcc). > I already know, your patch does not fix the automake stuff. Apart from that, there is another difference in way, how the INT_MAX issue is fixed. You include <limits.h>, which, of course, is part of glibc. However, in bug #218814 we include <climits>, which is part of gcc. It is the recommended way of fixing INT_MAX errors described at http://gcc.gnu.org/gcc-4.3/porting_to.html. So that is why I think it is rather gcc related. On the other hand <climits> is a C++ header, which includes <limits.h> itself, so maybe your solution is better and it should be decided by the developers.
I've got my variant from http://www.mail-archive.com/licq-dev@googlegroups.com/msg00730.html This bug appears if glibc 2.8 is installed, no matter if gcc version is 4.2 or 4.3. That's why I think it is glibc-related.
Fixed in 1.3.5-r1. Thanks for the patches!