Apache OpenOffice (AOO) Bugzilla – Issue 71111
OOE680_m1: sfx2/source/doc/docinf.cxx build error
Last modified: 2006-11-13 09:35:38 UTC
Hi, on GNU/Linux on x86_64, OOE680_m1: /data/oo/BuildDir/ooo_OOE680_m1_src/sfx2/source/doc/docinf.cxx: In member function 'BOOL SfxDocumentInfo::LoadFromBinaryFormat(SvStream&)': /data/oo/BuildDir/ooo_OOE680_m1_src/sfx2/source/doc/docinf.cxx:1717: error: no match for 'operator>>' in 'rStream >> ((SfxDocumentInfo*)this)->SfxDocumentInfo::nReloadSecs'
Appears to be a result of issue 54498, which introduced the change tools/inc/solar.h:1.41 < typedef sal_uInt32 ULONG; /* typedef unsigned long ULONG; */ --- > typedef sal_uIntPtr ULONG; /* typedef unsigned long ULONG; */ nReloadSecs is ULONG, SvStream has an operator >>(sal_uInt32 &), and until solar.h:1.40 everything happened to work. Probably best to change nReloadSecs to sal_uInt32.
it helped, yes -> sfx2 compiles.
.
The suggested by SB workaround is commited. But I would say that changing the size of the ULONG in this way is wrong, because ULONG was defined to support the common Windows types, and Windows documentation explicitly specifies ULONG as 32 bit.
mav: What exactly did you commit, please?
The commited files are sfx2/inc/docinf.hxx sfx2/source/doc/docinf.cxx
This issue has been reported for OOE680 m1, the fix went into SRC680. Do we need it on OOE680, too? Is there any risk in applying it to this release master (as mav said something about 'wrong fix' ...)
rt: it should be applied to OOE as well. The fix is safe.
The commited for this issue fix is completely OK. When I wrote '...I would say that changing the size of the ULONG in this way is wrong...', I have meant the new typedef for the ULONG type typedef sal_uIntPtr ULONG; introduced by fix for issue 54498.
OK, committed as masterfix to OOE680.
Closing.