[top posting] OK, my problems are not over. This time the build erred out in slideshow/test. It was odd because the compiles were OK but not the load.
I am not providing logs for this because something else, rather more drastic is happening! Here are my config options-- ./configure \ --build=i686-pc-linux-gnu \ --host=i686-pc-linux-gnu \ --target=i686-pc-linux-gnu \ --with-package-format="installed rpm" \ --disable-ldap \ --disable-beanshell \ --with-jdk-home=/etc/alternatives/java_sdk_openjdk \ --with-junit=/usr/share/java/junit4.jar \ --with-system-stdlibs \ --without-stlport \ --with-java \ --with-ant-home=/opt/ant \ --with-dmake-path=/usr/local/bin/dmake \ --without-ppds \ --with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz " \ --with-lang="en-US zh-CN" \ --with-perl-home=/usr \ --disable-directx \ --enable-dbus \ --disable-activex \ --disable-atl \ --disable-gnome-vfs \ --enable-verbose \ --enable-dbgutil \ --with-x normally with this I get about 31MB of output. More info -- gcc 4.4.7-16 gcc-c++ support for above version libgcc-4.4.7 libstdc++-4.4.7 Now, I am getting a HUGE amount of backtraces -- sample included here (this same error repeats a million times or so it seems). So my output file is about 10x the size it usually is! .Error: File /home/kschenk/AOO_source/openoffice/trunk/main/sal/cpprt/operators_new_delete.cxx, Line 91: operator delete mismatch Backtrace: [0] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/lib/libuno_sal.so.3: osl_assertFailedLine+0x150 Backtrace: [1] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x41467 Backtrace: [2] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x41661 Backtrace: [3] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZdlPv+0x23 Backtrace: [4] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZN5boost14checked_deleteIcEEvPT_+0x11 Backtrace: [5] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x38ce6 Backtrace: [6] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x371a4 Backtrace: [7] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x37216 Backtrace: [8] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x37268 Backtrace: [9] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZN6Export8CopyFileERK10ByteStringS2_+0x250 Backtrace: [10] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZN10HelpParser15MergeSingleFileEP7XMLFileR13MergeDataFileRK10ByteStringS4_+0x3e9 Backtrace: [11] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZN10HelpParser5MergeERK10ByteStringS2_S2_bRKSt6vectorIS0_SaIS0_EER13MergeDataFileb+0x60e Backtrace: [12] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: main+0x6b0 Backtrace: [13] /lib/libc.so.6: __libc_start_main+0xe6 Backtrace: [14] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x1c331 HELP! On 08/31/2015 09:12 AM, Kay Schenk wrote: > > > On 08/30/2015 11:52 PM, Damjan Jovanovic wrote: >> On Mon, Aug 31, 2015 at 5:54 AM, Damjan Jovanovic <dam...@apache.org> wrote: >>> On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk <kay.sch...@gmail.com> wrote: >>>> >>>> >>>> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: >>>>> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <kay.sch...@gmail.com> wrote: >>>>>> >>>>>> On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: >>>>>>> Hi >>>>>>> >>>>>>> I am in the process of migrating our unit tests from cppunit to Google >>>>>>> Test. However AOO doesn't build with cppunit and hasn't been routinely >>>>>>> built with cppunit for a while, which means our unit tests are in a >>>>>>> state of neglect, and unsurprisingly, there are many failures both >>>>>>> compiling and running our unit tests. >>>>>>> >>>>>>> Ideally we should investigate why and fix the tests. But the APIs >>>>>>> being tested are complex and unfamiliar to me (eg. SVG parsing), and >>>>>>> would take very long to investigate properly. >>>>>>> >>>>>>> I could commit changes that will just get the tests to compile, then >>>>>>> fail during testing and stop the build, thus forcing others to fix >>>>>>> them quickly :-), but I don't imagine that will go down well. So I am >>>>>>> taking this approach instead: >>>>>>> >>>>>>> // FIXME: >>>>>>> #define RUN_OLD_FAILING_TESTS 0 >>>>>>> >>>>>>> #if RUN_OLD_FAILING_TESTS >>>>>>> broken_test(); >>>>>>> #endif >>>>>>> >>>>>>> Also I am making unit tests run on every build. This way at least some >>>>>>> unit tests will be run, and any future regressions to tests can be >>>>>>> caught immediately, while the broken tests can be fixed gradually. >>>>>>> >>>>>>> Everyone happy? >>>>>> >>>>>> Well pretty much. :) >>>>>> >>>>>> I've been watching your commits. Thank you for taking on this >>>>>> challenging task. >>>>> >>>>> Thank you. >>>>> >>>>>> OK, just to be clear. It looks like you're converting the cppunit calls >>>>>> to Google Test api calls. But, what you're saying is the actual use of >>>>>> the Google test routines needs additional modification to work >>>>>> correctly, right? >>>>> >>>>> Yes that's what I am doing. >>>>> >>>>> No, the C++ conversions are very easy (feel free to help ;-)): >>>>> #include "cppunit..." => #include "gtest/gtest.h" >>>>> class X : public CppUnit::TestFixture => class X : public ::testing:Test >>>>> CPPUNIT_ASSERT_MESSAGE(msg, condition) => ASSERT_TRUE(condition) << >>>>> msg >>>>> CPPUNIT_ASSERT_EQUAL(c1, c2) => ASSERT_EQ(c1, c2) >>>>> CPPUNIT_FALSE(msg) => FAIL() << msg >>>>> private: => protected: >>>>> test methods move outside of class declaration and become >>>>> TEST_F(className, methodName) instead >>>>> CPPUNIT_TEST...() registrations disappear >>>>> >>>>> but the problem is that tests themselves are wrong no matter what the >>>>> testing library. For example: >>>>> basegfx::tools::importFromSvgD( aPoly, aSvg ); >>>>> won't compile, as importfromSvgD() requires 4 parameters now instead >>>>> of just 2 (as I explained in an earlier email, this was caused by >>>>> commit 1536730 on 2013-10-29 by alg). >>>>> >>>>> Damjan >>>> >>>> A quick question on these changes. Do these require a reconfigure to >>>> work correctly? I ran into a problem building with r1698208 so this is >>>> why I ask. >>>> >>> >>> I see, main/codemaker's tests don't build unless AOO is already built; >>> it's probably one of those tests that needs OOO_SUBSEQUENT_TESTS. >>> >>> r1698208 builds for me with this patch (ie. delete the last line of >>> text in main/codemaker/prj/build.lst): > > yes...that is what I did initially but, as you say... see below > >>> >>> Index: main/codemaker/prj/build.lst >>> =================================================================== >>> --- main/codemaker/prj/build.lst (revision 1700184) >>> +++ main/codemaker/prj/build.lst (working copy) >>> @@ -7,4 +7,3 @@ >>> cm codemaker\source\cppumaker nmake - all >>> cm_cppumaker cm_codemaker cm_cpp cm_inc NULL >>> cm codemaker\source\commonjava nmake - all >>> cm_java cm_inc NULL >>> cm codemaker\source\javamaker nmake - all >>> cm_javamaker cm_codemaker cm_java cm_inc NULL >>> -cm codemaker\test\cppumaker nmake - all >>> cm_cppumaker_test cm_cppumaker cm_codemaker cm_cpp cm_inc NULL >>> >>> However in the latest SVN I then get another build error in main/oovbaapi: >>> Compiling: Globals.idl >>> /tmp/idli_wyec6x: line 32: file 'com/sun/star/table/XCellRange.idl' not >>> found >>> AOO/main/solver/420/unxfbsdx/bin/idlc: preprocessing file >>> /AOO/main/oovbaapi/ooo/vba/excel/Globals.idl failed >>> dmake: Error code 1, while making '../../../unxfbsdx/ucr/excel.db' > > yep! same for me. > >>> >>> which isn't in a module I changed. I am bisection testing between >>> r1698208 and r1700184 to see what broke that. >> >> I fixed several problems and am busy rebuilding. Please check if the >> latest SVN works for you. If not, please post the build log. >> > > Thanks for your quick response. I'll be back in touch. > > -- -------------------------------------------- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
