"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes: > > http://sourceforge.net/tracker/index.php?func=detail&aid=773937&group_id=1107&atid=101107
That's a bug report against the LSB spec, not against lsbcc. As I understand it, the bug was resolved by saying that the LSB spec defers to POSIX, and that POSIX clearly requires <sys/types.h> to define size_t, so there's no need to change the LSB spec. > Given that three years have passed since that bug report, no bug > resolution is recorded, and my LSB compilers are new and dated > 2006-05-25, I doubt that another problem report would have any effect. But we're not talking about any bugs in the LSB spec; we're talking about a bug in lsbcc. Rajesh Banginwar of Intel found this problem last year, when porting ghostview 1.5 to LSB; see <http://developer.osdl.org/dev/dtl/docs/PortingToLinuxWebinar-08-2005.pdf> and search for size_t. Again, this was a bug in lsbcc, not in ghostview. His workaround, as shown in <http://lists.freestandards.org/pipermail/lsb-cvslog/2005-May/019854.html>, was to insert "typedef int size_t;" in the relevant module, which is clearly incorrect. As far as I know, he didn't understand the issue, so I'm not surprised he didn't report it as a bug in lsbcc. I'm afraid this doesn't inspire much confidence in the LSB process.
