Building SRC680_m52 (yes, I'm very patient...)
Milestone SRC680_m52 is tagged (not yet announced though). I have finished
build of it on
GNU/Linux and Solaris/SPARC, build on Windows is still running.
There are several identified/reported issues in this milestone. I hope this list can save you time
when you try building it. And please do not laugh when you read
... is now ready and no known
build problems are known.
- #i32707# -
binfilter: `acquire' undeclared (first use this function). Ken reported that this
issue is also present on HEAD. Fix is already mentioned in the issue but is not yet
integrated. It seems to be as simple as adding one #include:
Index: xmloff_SchXMLAutoStylePoolP.cxx
===================================================================
--- xmloff_SchXMLAutoStylePoolP.cxx (revision 59)
+++ xmloff_SchXMLAutoStylePoolP.cxx (revision 60)
@@ -58,6 +58,9 @@
*
*
************************************************************************/
+
+#include <xmlprmap.hxx>
+
// auto strip #include "SchXMLAutoStylePoolP.hxx"
#include "PropertyMap.hxx"
- #i33258# -
configure can't work with Sun WorkShop C compiler because of wrong merge (invalid
code). It also doesn't support Sun WorkShop C compiler 5.5 that I use on Solaris.
- #i33459# -
set_soenv.in is setting the variable DIRECTX_SUPPORT in the environment
file, but e.g. canvas or avmedia (on HEAD) is checking for
ENABLE_DIRECTX. For compilation on Windows, you need several files from HEAD!
- #i32042# -
desktop project depends on berkeleydb. I committed the fix to 20040815
so it will be integrated with this cws. But this is in milestones from about m46. It takes so
long to merge such build critical issues...
- #i32858# -
dbaccess: toolbox.hrc: No such file or directory. This is also fixed in 20040815.
- #i32398# - repeated
builds in
libxml2 result in a build failure. The patch
is attached in the issue.
- #i32565# - repeated
builds in
officecfg result in a build failure. The patch is not attached in the
issue, because it is simply about adding missing underscore in
$(MISC)$/$(TARGET)_delzip target.
- #i33481# - this issue is
multi-project. Several files are affected:
autodoc/source/ary/inc/nametreenode.hxx,
autodoc/source/ary/store/t_storg.hxx, stoc/source/security/lru_cache.h,
ucb/source/inc/regexpmap.tpt. The typename was brought in by gcc34
changes but these changes broke .NET2002 compiler on Windows. We probably need to invent
a mechanism to overcome this bug, because we want both .NET2002 and .NET2003 to be supported
compilers.
- #i33287# - two files
(
dp_parceldesc.cxx and dp_sfwk.cxx) in desktop project use
the function OUStringToOString without rtl:: prefix.
- #i33509# -
nsplugin uses gtk/gtk.h include file, but doesn't add proper include
paths in CFLAGS.
- #i33458# - repeated
builds in
scripting/java fails on Windows. Temporary fix is in the issue - simply
remove clean target from dependencies. Scripting project has several other
minor/non-build issues (#i33504#).
- #i31666# -
solenv/inc/unitools.mk still needs to define several tools for cygwin/tcsh builds on
Windows.
- #i33009# -
solenv/inc/wnt.mk contains wrong prefixes for options Zc:forScope and
GR.
- #i29787# -
solenv/bin/guw.pl needs two changes to support options like Zc:forScope
(see above #i33009#) and
delayload.
Update:
- #i33528# -
sc/source/core/data/compressedarray.cxx compilation failure.
- #i30357# -
solenv/inc/packtools.mk wrongly assume that rpm and
rpmbuild are installed in the same directory.
It seems that we have to invent a mechanism to not propagate those build critical issues between
milestones and quickly fix them on HEAD. I proposed this solution on IRC (sorry for my English):
with each and every milestone (like this one, SRC680_m52), new really-short-term child workspace
named like build_only_fixes_src680_m52 (or similar) will be opened. It will stay opened for short
time like three or four days and people will commit only build fixes there so this cws will be QA'ed
and integrated just before the next milestone is to be prepared. It has several advantages: build
critical fixes will be integrated much faster than now, people will start to use milestones because
right now they can't (see the list of issues above) thus OpenOffice.org 2.0 will get much more
testing. I'd like to hear your opinions (on IRC, of course ;-).
-----