Web/App Development Services
PS: If you do not wish to hear from us. Please click here Hi, Would you be interested in building your website? We are a professional web design company based in India. We are expert in the following: • Joomla Websites • Word press Websites • Magneto Websites • Shopify Websites • Drupal Website • E-Commerce Solutions • Payment Gateway Integration • Custom Websites • Mobile Apps • Digital Marketing If you want to know the price/cost and examples of our website design project, please share your requirements and website URL. We have a long list of happy clients and we would love to have you as our next client. Warm Regards, John Smith Business Development Executive Global Offices: Perth| San Francisco | Los Angeles | India * Don't want to receive these emails in the future? reply to this email with 'Unsubscribe' in the subject line.___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LibreOffice fuzz-testing
On Tue, Apr 22, 2014 at 5:33 PM, Keith Curtis wrote: > > I don't think it is worth abandoning just because it is in separate languages. > Maybe. However, I did run into something else that is worth abandoning it for. Im have been using the pseudonym of 'John Smith, lbalba...@gmail.com' for quite a few years now, for various reasons. Not disclosing my real name could potentially mean future problems for the LibreOffice project. One place where issues could occur, is where contributors need to digitally make/mail a legally binding statement that all of their contributions may be licensed under the MPL/GPL. Dont get me wrong: I have no issue whatsoever with the MPL/GPL licenses, but being unwilling to put my real name under that statement may mean trouble for the project. Because I mean the project no harm, not even imaginary, I decided to abandon the code. In all fairness: I was offered the chance of only making my real name known to the legal department, and keeping my pseudonym in all other cases. But I guess im to paranoid for even that. Anyway, im currently re-evaluating my need for a pseudonym, and may decide to contribute to the project using my real name sometime in the future. Regards, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
License statement
Hi, All of mine past & future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license. Regards, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LibreOffice fuzz-testing
Hi, In theory, I agree with you that it would be nicer if the entire thing would have been written in a single language. In practice, however : The fuzzer was already written, and in perl: Morten Welinder (of gnumeric fame) wrote a perl XML fuzzer - which you can find here: http://git.gnome.org/browse/gnumeric/tree/test/fuzzxml. So I took that. (the bug report references that code). The code to make libreoffice open and close documents was already there, in 'dev-tools/test-bugzilla-filestest-bugzilla-files.py'. So I took that, and only took out the parts I didnt need (file validation, etc). Now I know neither python nor perl; but i can do some unix shell scripting. So the fact that made it an 'EasyHack' for me was, that the hard parts were already written and I 'only' had to glue the stuff together using Unix shell scripting. Sadly, re-coding it in either perl or python in its entirety is beyond my current skill set; so if that would turn out to be a requirement then im afraid i have to abandon the easyhack bug and let others step in. We may want to continue this discuss this point on list or in the gerrit review though; its a valid point. Regards, John Smith. On Mon, Apr 21, 2014 at 10:58 PM, Keith Curtis wrote: > It looks interesting. The only thing I noticed is that it is written > in both Perl and Python. I'm no Python expert yet, but I've done some, > and never written Perl. > > I think it would be nice if small tools like this were all in one > language, to lessen the requirements for someone to be able to > contribute. The number of people who know Python is 100x greater than > the number of people who know both Perl and Python. > > What do you think? > > -Keith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[no subject]
Hi, I attempted to make an implementation of easyhack bug #38841. Basically its a shell script that fuzzes the xml files inside libreoffice doc formats, and then feeds the fuzzed docs to libreoffice. Code is here: https://gerrit.libreoffice.org/9114 In order to make things work: edit fuzz-xml-files/etc/fuzz-xml-files.conf and point the vars to sensible directories: SRC_DIR= the top level location of your libreoffice source code DOC_DIR= a directory containing odf odt etc files for the other vars you may need to change '/usr/local/src/dev-tools' to '/some/other/dir/dev-tools' run it: cd dev-tools/fuzz-xml-files/ ./fuzz-xml-files.sh its got some command line switches but the defaults should 'just work' as long as the vars in the conf file point to sensible stuff. Eagerly awaiting feedback, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Need help for fdo#490941
Perhaps, in an ideal world, it is user configurable (the user gets to choose) whether, in case of conflict, system default key-assignments can be overridden by custom user assignments or not. ? On Fri, Apr 18, 2014 at 5:59 PM, Rachit Gupta wrote: > Hello everyone, > > I'm working on fdo#49091 > (https://bugs.freedesktop.org/show_bug.cgi?id=49091), according to the > comment posted on it recently, when a table is being edited and the user > presses Alt+Left, then the default action is to reduce the column width. But > if the user has assigned a separate action to Alt+Left, then that action is > to be performed as well? > > > Regards, > Rachit Gupta > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'test-bugzilla-files.py' dependencies
On Wed, Apr 16, 2014 at 10:03 AM, Markus Mohrhard wrote: > > On Apr 16, 2014 9:35 AM, "John Smith" wrote: >> >> On Wed, Apr 16, 2014 at 9:30 AM, John Smith wrote: >> > >> > For odftoolkit, I can run 'mvn install' in the top level source >> > directory, which gets me >> > './odfdom/target/odfdom-java-0.8.9-incubating.jar'. Same question: >> > just copy the jar to another directory and run it with java -jar >> > foo.jar ? >> > >> Oops, I mean >> './validator/target/odfvalidator-1.1.6-incubating-jar-with-dependencies.jar', >> of course. > > That is the correct one. Just rename it for the script. For officeotron you > can't use the war file. There is a build option to build the command line > version. Please check The build script. > Thanks. I assume you mean the build.xml file ? Ive looked through that, but managed to find nothing that's obviously supposed to be a build option. Anyway, after 'ant' in the top level source dir I get both 'dist/officeotron-0.7.0.war' and 'dist/officeotron-0.7.0.jar'. I assume I can just copy the jar file and leave the war alone ? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'test-bugzilla-files.py' dependencies
On Wed, Apr 16, 2014 at 9:30 AM, John Smith wrote: > > For odftoolkit, I can run 'mvn install' in the top level source > directory, which gets me > './odfdom/target/odfdom-java-0.8.9-incubating.jar'. Same question: > just copy the jar to another directory and run it with java -jar > foo.jar ? > Oops, I mean './validator/target/odfvalidator-1.1.6-incubating-jar-with-dependencies.jar', of course. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'test-bugzilla-files.py' dependencies
Hi, Thanks for those url's. I downloaded the sources 'officeotron-source-0.7.0.zip' and 'odftoolkit-0.6-incubating-src.zip', but am a bit unsure about how to compile and run the programs. I unzipped both files. For officeotron, I can run 'ant' in the top level source directory, which gets me './dist/officeotron-0.7.0.jar'. Can I simply copy that to another directory, like for example '/home/buildslave/source/bin/', and then proceed to run it from there with 'java -jar foo.jar' ? For odftoolkit, I can run 'mvn install' in the top level source directory, which gets me './odfdom/target/odfdom-java-0.8.9-incubating.jar'. Same question: just copy the jar to another directory and run it with java -jar foo.jar ? Thanks, Regards, John Smith On Wed, Apr 16, 2014 at 7:10 AM, Markus Mohrhard wrote: > > https://code.google.com/p/officeotron/ > > http://incubator.apache.org/odftoolkit/conformance/ODFValidator.html > > Regards, > Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
'test-bugzilla-files.py' dependencies
Hi, When I attempt to run 'dev-tools/test-bugzilla-filestest-bugzilla-files.py', it seems to have some dependencies that i cant find anywhere in the repository's. In particular, the script attempts to load these jar files : /home/buildslave/source/bin/odfvalidator.jar /home/buildslave/source/bin/officeotron.jar Is there a repository i can check out to get a copy of those files ? Are there any other dependencies for 'test-bugzilla-files.py' ? Thanks, Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'test-bugzilla-files.py' issues
On Tue, Apr 15, 2014 at 8:37 PM, Markus Mohrhard wrote: > > It is a feature that it does not look in sub directories. That allows me > some freedom in organizing documents and moving broken documents around > without too much work. So I would be a bit reluctant to change that behavior > as it will break the script on the server. You can just use a script similar > to the one that I posted for you that iterates over all directories and > inspects each one. > Ok, guess ill just do something like this then: for dir in ./libreofficedocs/* do test-bugzilla-files.py $dir done or : find ./libreofficedocs/ -type d | while read dir do test-bugzilla-files.py $dir done Thanks for the help, Regards, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'test-bugzilla-files.py' issues
On Tue, Apr 15, 2014 at 6:53 PM, Markus Mohrhard wrote: > > I already mentioned on IRC that this means it just did not find any test > files. The connection is working otherwise the NoConnectException would be > repeated. You need to make sure that you point to the correct directory and > otherwise debug why the script is not finding the files in your case. It > works for me so I can't tell you what is wrong in your setup. > Hi, I think I got it. When I remove the comments before 'print(files)' and 'print( dirs )', I only see the subdirs below /usr/local/src/libreofficedocs/, but not the files located in those subdirs. When I copy a file directly in libreofficedocs, the script does find it. Looks like test-bugzilla-files.py doesnt descend into the subdirectory's. Since 'dev-tools/test-bugzilla-files/test-bugzilla-files.py' created this directory structure, I assumed that test-bugzilla-files.py would be able to parse that. I know next time nothing about python, but would it be possible and reasonably easy/quick to make test-bugzilla-files.py look in all subdirectory's you point it at too ? Thanks for all the help, Regards, John Smith. # find /usr/local/src/libreofficedocs/ -type d /usr/local/src/libreofficedocs/ /usr/local/src/libreofficedocs/sxg /usr/local/src/libreofficedocs/pgm /usr/local/src/libreofficedocs/wmf /usr/local/src/libreofficedocs/psd /usr/local/src/libreofficedocs/xpm /usr/local/src/libreofficedocs/odb /usr/local/src/libreofficedocs/docx /usr/local/src/libreofficedocs/xlsx /usr/local/src/libreofficedocs/docbook /usr/local/src/libreofficedocs/pbm /usr/local/src/libreofficedocs/pcx /usr/local/src/libreofficedocs/svm /usr/local/src/libreofficedocs/cwk /usr/local/src/libreofficedocs/doc /usr/local/src/libreofficedocs/sgf /usr/local/src/libreofficedocs/sdd_i /usr/local/src/libreofficedocs/xltm /usr/local/src/libreofficedocs/ras /usr/local/src/libreofficedocs/dbf /usr/local/src/libreofficedocs/xltx /usr/local/src/libreofficedocs/cmx /usr/local/src/libreofficedocs/psw /usr/local/src/libreofficedocs/dxf /usr/local/src/libreofficedocs/sds /usr/local/src/libreofficedocs/sdp5 /usr/local/src/libreofficedocs/sti /usr/local/src/libreofficedocs/met /usr/local/src/libreofficedocs/vdx /usr/local/src/libreofficedocs/ppt /usr/local/src/libreofficedocs/potm /usr/local/src/libreofficedocs/sgl5 /usr/local/src/libreofficedocs/pcd /usr/local/src/libreofficedocs/pdb_palm /usr/local/src/libreofficedocs/smf5 /usr/local/src/libreofficedocs/xls /usr/local/src/libreofficedocs/ppotx /usr/local/src/libreofficedocs/pptm /usr/local/src/libreofficedocs/odt /usr/local/src/libreofficedocs/fods /usr/local/src/libreofficedocs/sdd_d /usr/local/src/libreofficedocs/sxs /usr/local/src/libreofficedocs/oth /usr/local/src/libreofficedocs/sxd /usr/local/src/libreofficedocs/sxm /usr/local/src/libreofficedocs/odg /usr/local/src/libreofficedocs/pdb_plucker /usr/local/src/libreofficedocs/otc /usr/local/src/libreofficedocs/602 /usr/local/src/libreofficedocs/tiff /usr/local/src/libreofficedocs/sxc /usr/local/src/libreofficedocs/pptx /usr/local/src/libreofficedocs/otg /usr/local/src/libreofficedocs/otp /usr/local/src/libreofficedocs/xlsm /usr/local/src/libreofficedocs/odm /usr/local/src/libreofficedocs/svg /usr/local/src/libreofficedocs/pict /usr/local/src/libreofficedocs/rtf /usr/local/src/libreofficedocs/docm /usr/local/src/libreofficedocs/eps /usr/local/src/libreofficedocs/fodg /usr/local/src/libreofficedocs/lrf /usr/local/src/libreofficedocs/key /usr/local/src/libreofficedocs/sldm /usr/local/src/libreofficedocs/sdd5 /usr/local/src/libreofficedocs/ppm /usr/local/src/libreofficedocs/sdw /usr/local/src/libreofficedocs/sds5 /usr/local/src/libreofficedocs/mml /usr/local/src/libreofficedocs/odf /usr/local/src/libreofficedocs/odp /usr/local/src/libreofficedocs/fodp /usr/local/src/libreofficedocs/dotm /usr/local/src/libreofficedocs/ppsm /usr/local/src/libreofficedocs/std /usr/local/src/libreofficedocs/cgm /usr/local/src/libreofficedocs/xbm /usr/local/src/libreofficedocs/wks /usr/local/src/libreofficedocs/wpg /usr/local/src/libreofficedocs/wpd /usr/local/src/libreofficedocs/ods /usr/local/src/libreofficedocs/sldx /usr/local/src/libreofficedocs/fb2 /usr/local/src/libreofficedocs/odc /usr/local/src/libreofficedocs/sdc /usr/local/src/libreofficedocs/ott /usr/local/src/libreofficedocs/sdc5 /usr/local/src/libreofficedocs/ots /usr/local/src/libreofficedocs/smf /usr/local/src/libreofficedocs/tga /usr/local/src/libreofficedocs/sxw /usr/local/src/libreofficedocs/pdb /usr/local/src/libreofficedocs/emf /usr/local/src/libreofficedocs/vsd /usr/local/src/libreofficedocs/otf /usr/local/src/libreofficedocs/hwp /usr/local/src/libreofficedocs/stc /usr/local/src/libreofficedocs/fodt /usr/local/src/libreofficedocs/cdr /usr/local/src/libreofficedocs/html /usr/local/src/libreofficedocs/bmp /usr/local/src/libreofficedocs/sxi /usr/local/src/libreofficedocs/ppsx /usr/local/src/libr
Re: 'test-bugzilla-files.py' issues
Markus, Stephan: Thanks. I rebuild with './configure --enable-python=internal', but I still get the same results: # pwd /usr/local/src # /usr/local/src/libreoffice/instdir/program/python dev-tools/test-bugzilla-files/test-bugzilla-files.py --soffice=path:/usr/local/src/libreoffice/instdir/program/soffice --userdir=file:///tmp/.config/libreoffice/4 /usr/local/src/libreofficedocs/ 12128 OfficeConnection: connecting to: uno:pipe,name=pytest548aca44-c4b8-11e3-83c3-000c29d3;urp;StarOffice.ComponentContext NoConnectException: sleeping... kill kill 12128 Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'test-bugzilla-files.py' issues
On Tue, Apr 15, 2014 at 12:57 PM, Stephan Bergmann wrote: > > * Never start soffice.bin directly, always use soffice instead. > Thanks, ill do that from now on. Ive re-tried with using 'soffice' instead of 'soffice.bin', and the results are the same: using soffice directly works. > > * At least in current gerrit.libreoffice.org/dev-tools there is no > dev-tools/test-bugzilla-files.py, > but only non-executable dev-tools/test-bugzilla-files/test-bugzilla-files.py > Im sorry, I cut n pasted that incorrectly in my email. You are right, I mean (and have been using) the non-executable dev-tools/test-bugzilla-files/test-bugzilla-files.py > > that you need to run as "/usr/local/src/libreoffice/instdir/program/python > dev-tools/test-bugzilla-files/test-bugzilla-files.py ..." > Hrm. I must be doing something wrong with the build then, because i dont have a '/usr/local/src/libreoffice/instdir/program/python' # find /usr/local/src/libreoffice -name python /usr/local/src/libreoffice/workdir/ScpTarget/scp2/source/python /usr/local/src/libreoffice/workdir/ScpPreprocessTarget/scp2/source/python /usr/local/src/libreoffice/workdir/AutoInstall/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/doc/html/boost/mpi/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/boost/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/boost/parameter/aux_/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/boost/mpi/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/tools/quickbook/test/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/libs/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/libs/python/doc/tutorial/doc/html/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/libs/mpi/example/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/libs/mpi/src/python /usr/local/src/libreoffice/workdir/UnpackedTarball/boost/libs/mpi/test/python /usr/local/src/libreoffice/instdir/share/Scripts/python /usr/local/src/libreoffice/instdir/sdk/examples/python /usr/local/src/libreoffice/odk/examples/python /usr/local/src/libreoffice/sw/qa/python /usr/local/src/libreoffice/scripting/examples/python /usr/local/src/libreoffice/scp2/source/python /usr/local/src/libreoffice/unotest/source/python Regards, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
'test-bugzilla-files.py' issues
Hi, I seem to have some issues starting and/or connecting to soffice in headless mode. When i run 'soffice.bin -env:UserInstallation=file:///tmp/.config/libreoffice/4 --accept="pipe,name=pytest50f337fa-c471-11e3-93ba-000c29d3;urp" --quickstart=no --nofirststartwizard --norestore --nologo --headless --nodefault' 'lsof' shows the soffice pipe is created successfully. But when I run 'dev-tools/test-bugzilla-files.py --soffice=path:/usr/local/src/libreoffice/instdir/program/soffice --userdir=file:///tmp/.config/libreoffice/4 /usr/local/src/libreofficedocs/', the connection fails. The same thing happens when i use sockets instead of named pipes. This listens on a socket: soffice --headless --invisible --nologo --norestore "--accept=socket,port=8100" But this doesnt: python dev-tools/test-bugzilla-files.py --soffice=connect:socket,port=8100 /usr/local/src/libreofficedocs/ 'dev-tools/test-bugzilla-files.py' basically does the same thing as what i do on the command line. If anyone has an idea of what could be going wrong, or where to start troubleshooting, any and all help is appreciated. Thanks, Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Writing MS Visio Format
On Tue, Apr 8, 2014 at 7:42 AM, David Tardon wrote: > Hi, > > On Tue, Apr 08, 2014 at 07:31:23AM +0200, John Smith wrote: >> On Tue, Apr 8, 2014 at 12:43 AM, Mat M wrote: >> > >> > .vsdx (Visio XML format) could be a solution. There are some links with >> > more >> > or less extensive description of the format [0]. Would it fit your purpose >> > ? >> > >> Well I tried this in practice, by creating a new drawing in Visio 2013 >> and saving it as vsdx, but it resulted in a binary file and not xml ? >> Not sure what that means, though. > > VSDX is ZIP with a bunch of XML files inside. > > D. Ah. I didnt know that. Thanks! ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Writing MS Visio Format
On Tue, Apr 8, 2014 at 7:31 AM, John Smith wrote: > > Unfortunately I ran into this issue [1] when saving vsd as svg in > Visio, and then opening it in Draw. Not sure if it's a bug in Visio or > in Draw, though. > Ooops. I mean, opening VSD in LibreOffice, exporting it as SVG in LibreOffice, and then opening the exported SVG file in LibreOffice again. Sorry for the confusion, my mistake. Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Writing MS Visio Format
On Tue, Apr 8, 2014 at 12:43 AM, Mat M wrote: > > .vsdx (Visio XML format) could be a solution. There are some links with more > or less extensive description of the format [0]. Would it fit your purpose ? > Well I tried this in practice, by creating a new drawing in Visio 2013 and saving it as vsdx, but it resulted in a binary file and not xml ? Not sure what that means, though. > > And AFAIK, Visio ocul dimport svg, that Draw is able to export. It could be > a workaround. > Thanks. I noticed this option in Visio 2013, but dont know if earlier versions of Visio can import svg as well. If earlier versions can as well, it could be a workaround. Unfortunately I ran into this issue [1] when saving vsd as svg in Visio, and then opening it in Draw. Not sure if it's a bug in Visio or in Draw, though. Regards, John Smith. [1: https://bugs.freedesktop.org/show_bug.cgi?id=76988 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Writing MS Visio Format
Hi, I know LibreOffice can open/read Visio .vsd files, but are there any plans to add exporting/saving to visio .vsd format ? LibreOffice seems to be unable to do that at this point (4.2.2.1) Thanks, Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: 'make build-nocheck' failure
> -Original Message- > From: libreoffice-bounces+lbalbalba=gmail@lists.freedesktop.org > [mailto:libreoffice-bounces+lbalbalba=gmail@lists.freedesktop.org] On > Behalf Of David Tardon > Sent: Thursday, December 20, 2012 8:29 AM > To: libreoffice@lists.freedesktop.org > Subject: Re: 'make build-nocheck' failure > > > Yes, I do. StaticLibrary pdfimport_s needs that CustomTarget (the > hash.cxx file the CustomTarget produces is included in > sdext/source/pdfimport/wrapper/wrapper.cxx), but it is only listed in > gb_Module_add_check_targets. Fixed now. > > D. > Thanks. Happily building build-nocheck now. Regards, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: lcov report: which directory's to filter out ?
Thanks very much. Ive updated the lcov wiki page. - John Smith -Original Message- From: David Tardon [mailto:dtar...@redhat.com] Sent: Wednesday, December 19, 2012 7:55 AM To: John Smith Cc: libreoffice@lists.freedesktop.org Subject: Re: lcov report: which directory's to filter out ? Hi, On Mon, Dec 17, 2012 at 06:25:48PM +0100, John Smith wrote: > Hi, > > > I have made a new lcov code coverage report over at: > http://dev-builds.libreoffice.org/lcov_reports/master~2012-12-15_08.47 > .02/ > > As I ran all tests in 'make test' now, instead of stopping when a > single one fails (I had a lot of failures though) it should be at > least a somewhat more accurate description of the code that is covered > by the tests. > > But maybe it still contains some directory's that should better be > filtered out ? I already filtered out '/usr/include/*' and > '/usr/lib/*', but maybe outhers should be too ? dmake workdir/*/UnpackedTarball/* D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: MS Word import: bug-to-bug or "correct"
Hi, Just for clarification: Are we talking about an ill-formed or corrupted document here, and the way such documents should be handled ? Regards, John Smith. On Tue, Dec 18, 2012 at 2:51 PM, Lionel Elie Mamane wrote: > Hi, > > What is our policy about MS Word import? Should it give the same > result as in MS Word, or where MS Word is buggy it should give a > "correct" result? > > I ask this in context of the attached bug. > > -- > Lionel > > > -- Forwarded message -- > From: bugzilla-dae...@freedesktop.org > To: lio...@mamane.lu > Cc: > Date: Tue, 18 Dec 2012 08:58:25 + > Subject: [Bug 49306] FILEOPEN catastrophically bad import of one specific > .doc (Microsoft Word) document > https://bugs.freedesktop.org/show_bug.cgi?id=49306 > > ydutri...@gmail.com changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution|--- |NOTABUG > > -- > You are receiving this mail because: > You reported the bug. > > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: undefined reference to `__gcov_init' when using FLAGS+='-fprofile-arcs -ftest-coverage'
On Mon, Dec 17, 2012 at 10:20 AM, David Tardon wrote: > Hi, > > The old build system looks for ENVLINKFLAGS variable. So if you set > ENVLINKFLAGS to the same value as LDFLAGS, the build should pass. > > D. > Thanks, that works great. Added it to the lcov wiki page. Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
lcov report: which directory's to filter out ?
Hi, I have made a new lcov code coverage report over at: http://dev-builds.libreoffice.org/lcov_reports/master~2012-12-15_08.47.02/ As I ran all tests in 'make test' now, instead of stopping when a single one fails (I had a lot of failures though) it should be at least a somewhat more accurate description of the code that is covered by the tests. But maybe it still contains some directory's that should better be filtered out ? I already filtered out '/usr/include/*' and '/usr/lib/*', but maybe outhers should be too ? I also excluded branch coverage data for this report (including it takes longer, and the default is 'off'), as I wasnt sure about the interest in it. Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Running all 'make check' targets, even when some fail ?
On Mon, Dec 17, 2012 at 10:41 AM, John Smith wrote: > On Mon, Dec 17, 2012 at 10:30 AM, Stephan Bergmann > wrote: >> >> Looking into Makefile.top, it might work to do >> >> GMAKE_OPTIONS=-rsk make check >> > Thanks. > > Adding 'k' to GMAKE_OPTIONS in Makefile.top and then running make > check seems to work. Lets see if it continues when the first check > fails. Yup, that works great. - John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Running all 'make check' targets, even when some fail ?
On Mon, Dec 17, 2012 at 10:30 AM, Stephan Bergmann wrote: > > Looking into Makefile.top, it might work to do > > GMAKE_OPTIONS=-rsk make check > Thanks. Adding 'k' to GMAKE_OPTIONS in Makefile.top and then running make check seems to work. Lets see if it continues when the first check fails. ;) Thanks again, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Running all 'make check' targets, even when some fail ?
On Mon, Dec 17, 2012 at 10:05 AM, Rene Engelhard wrote: > Hi, > > make -k check works here. See e.g. > https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=1%3A3.6.4-1&stamp=1355234789 > (than again I have a patch to not run *any* check-related things > during "normal" make build and run make -k check afterwards, but...) > Thanks for the feedback. I do a 'make build', and then a 'make -k check' afterwards. maybe im just misreading the output ? I get this; the -k seems to be dropped ? : # make -k check make -r -f /usr/local/src/libreoffice/Makefile.top check make[1]: Entering directory `/usr/local/src/libreoffice' cd /usr/local/src/libreoffice/packimages && unset MAKEFLAGS && \ /usr/local/src/libreoffice/solenv/bin/build.pl -P2 --all -- -P2 && \ make -j 2 -rs sysui depends on tail_build[offapi] sysui depends on tail_build[l10ntools] setup_native depends on tail_build[sal] setup_native depends on tail_build[l10ntools] helpcontent2 depends on tail_build[xmlhelp] = (1/11) Building module solenv = Entering /usr/local/src/libreoffice/solenv/prj gbuild module /usr/local/src/libreoffice/solenv: make -f Makefile -j2 -rs all slowcheck gb_PARTIALBUILD=T [build ALL] top level modules: solenv [build ALL] loaded modules: solenv [build CHK] loaded modules: solenv [build SLC] loaded modules: solenv solenv deliver = (2/11) Building module soltools = = (3/11) Building module stlport = = (4/11) Building module python3 = Entering /usr/local/src/libreoffice/soltools/prj Entering /usr/local/src/libreoffice/stlport gbuild module /usr/local/src/libreoffice/soltools: make -f Makefile -j2 -rs all slowcheck gb_PARTIALBUILD=T dmake: makefile.mk: line 129: Warning: -- Macro `CXX' redefined after use Entering /usr/local/src/libreoffice/python3/prj gbuild module /usr/local/src/libreoffice/python3: make -f Makefile -j2 -rs all slowcheck gb_PARTIALBUILD=T [build ALL] top level modules: soltools [build ALL] loaded modules: soltools [build CHK] loaded modules: soltools [build SLC] loaded modules: soltools soltools deliver stlport deliver Module 'stlport' delivered successfully. 0 files copied, 2 files unchanged = (5/11) Building module external = Entering /usr/local/src/libreoffice/external/gcc3_specific Entering /usr/local/src/libreoffice/external/glibc external deliver Module 'external' delivered successfully. 0 files copied, 15 files unchanged [build ALL] top level modules: python3 [build ALL] loaded modules: python3 [build CHK] loaded modules: python3 [build SLC] loaded modules: python3 python3 deliver = (6/11) Building module tail_build = Entering /usr/local/src/libreoffice/tail_build/prj gbuild module /usr/local/src/libreoffice/tail_build: make -f Makefile -j2 -rs all slowcheck gb_PARTIALBUILD=T ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Running all 'make check' targets, even when some fail ?
Hi, Im looking for a way to run all the targets in 'make check', even if some of them fail, because that would be a more accurate picture of how much code is covered by the tests. I looked at 'make -k', but the '-k' seems to be lost in the build system somewhere. Is there a way to list all the make test targets or something, so I can loop over those in a shell script ? (I dont know much about Makefiles.) Other ideas are welcome too. ;) Regards. John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Personas in LibreOffice
Sorry, really have no business in this thread, but I just couldnt resist... Why not 'best of both worlds' ? Allow user persona's, and improve the default look ? you could even do a contest, where the best user persona wins to be the new default look ? just my 2 $ Well, shutting up now again... - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: is 'make check' supposed to work on ~master ?
On Fri, Dec 14, 2012 at 8:00 AM, Noel Grandin wrote:
>
> On 2012-12-13 19:28, John Smith wrote:
>>
>> Conditional jump or move depends on uninitialised value(s)
>
> That looks like you have valgrind enabled, and I don't think all of our unit
> tests have been made valgrind-safe yet.
>
Oh. Well, when I do 'make build' without valgrind, I get a segmentation fault :
[build CUT] sw_subsequent_rtfexport
[build CUT] sw_subsequent_rtfimport
/bin/sh: line 1: 4079 Segmentation fault (core dumped)
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$O/lib":$O/lib/sqlite
DBGSV_ERROR_OUT=shell DISABLE_SAL_DBGBOX=t STAR_RESOURCEPATH=$O/bin/
$O/bin/cppunit/cppunittester
$W/LinkTarget/CppunitTest/libtest_sw_subsequent_ww8export.so
--headless "-env:BRAND_BASE_DIR=file://$O/unittest/install"
"-env:CONFIGURATION_LAYERS=xcsxcu:file://$O/xml/registry
module:file://$O/xml/registry/spool
xcsxcu:file://$O/unittest/registry"
"-env:UNO_TYPES=file://$O/bin/offapi.rdb file://$O/bin/udkapi.rdb"
"-env:UNO_SERVICES=file://$O/xml/ure/services.rdb
file://$O/xml/component/basic/util/sb.component
file://$O/xml/component/comphelper/util/comphelp.component
file://$O/xml/component/configmgr/source/configmgr.component
file://$O/xml/component/dbaccess/util/dba.component
file://$O/xml/component/embeddedobj/util/embobj.component
file://$O/xml/component/fileaccess/source/fileacc.component
file://$O/xml/component/filter/source/config/cache/filterconfig1.component
file://$O/xml/component/forms/util/frm.component
file://$O/xml/component/framework/util/fwk.component
file://$O/xml/component/i18npool/util/i18npool.component
file://$O/xml/component/linguistic/source/lng.component
file://$O/xml/component/package/source/xstor/xstor.component
file://$O/xml/component/package/util/package2.component
file://$O/xml/component/sax/source/expatwrap/expwrap.component
file://$O/xml/component/sw/util/msword.component
file://$O/xml/component/sw/util/sw.component
file://$O/xml/component/sw/util/swd.component
file://$O/xml/component/sfx2/util/sfx.component
file://$O/xml/component/svl/source/fsstor/fsstorage.component
file://$O/xml/component/svtools/util/svt.component
file://$O/xml/component/toolkit/util/tk.component
file://$O/xml/component/ucb/source/core/ucb1.component
file://$O/xml/component/ucb/source/ucp/file/ucpfile1.component
file://$O/xml/component/unotools/util/utl.component
file://$O/xml/component/unoxml/source/service/unoxml.component
file://$O/xml/component/xmlhelp/util/ucpchelp1.component"
-env:URE_INTERNAL_LIB_DIR=file://$O/lib -env:LO_LIB_DIR=file://$O/lib
--protector unoexceptionprotector.so unoexceptionprotector --protector
unobootstrapprotector.so unobootstrapprotector >
$W/CppunitTest/sw_subsequent_ww8export.test.log 2>&1
OK (1)
Error: a unit test failed, please do one of:
export DEBUGCPPUNIT=TRUE# for exception catching
export GDBCPPUNITTRACE="gdb --args" # for interactive debugging
export VALGRIND=memcheck# for memory checking
and retry.
make[2]: ***
[/usr/local/src/libreoffice/workdir/unxlngi6.pro/CppunitTest/sw_subsequent_ww8export.test]
Error 1
make[2]: *** Waiting for unfinished jobs
---
Oh dear - something failed during the build - sorry !
For more help with debugging build errors, please see the section in:
http://wiki.documentfoundation.org/Development
internal build errors:
ERROR: error 512 occurred while making /usr/local/src/libreoffice/tail_build/prj
it seems that the error is inside 'tail_build', please re-run build
inside this module to isolate the error and/or test your fix.
---
To rebuild a specific module:
make tail_build.clean # not recommended, this will re-build almost everything
make tail_build
when the problem is isolated and fixed, re-run 'make'
make[1]: *** [build-packimages] Error 1
make[1]: Leaving directory `/usr/local/src/libreoffice'
make: *** [build] Error 2
[root@localhost libreoffice]# gdb
/usr/local/src/libreoffice/solver/unxlngi6.pro/bin/cppunit/cppunittester
./tail_build/core.4079
GNU gdb (GDB) Fedora (7.4.50.20120120-49.fc17)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/usr/local/src/libreoffice/solver/unxlngi6.pro/bin/cppunit/cppunittester...(no
debugging symbols found)...done.
[New LWP 4079]
[New LWP 4080]
warning:
Re: Not Receiving "Replies" Correctly - Ideas?
Havent got a clue, but - Did you receive this reply ? - Is the reply email showing up when you use your browser to access your email instead of using Thunderbird ? - Is the reply in the Thunderbird or web Gmail SPAM box just my 2$, sorry i cant be of more help here. - John Smith. On Thu, Dec 13, 2012 at 9:03 PM, Joel Madero wrote: > Hi All, > > This is becoming a serious issue on my side and I wanted feedback. Earlier I > sent out an email to Libo-QA and LibO user mailing list about our conference > call tomorrow. Two people replied but I didn't get the replies, instead Rob > pointed out that he had replied and I responded that I hadn't received any > reply. > > http://nabble.documentfoundation.org/Libreoffice-qa-LibreOffice-QA-Conference-Call-December-14th-2012-1400-UTC-td4024195.html > > That's the full conversation, I only have the sent item that I sent, not the > reply by Florian and Rob.I need a solution if I'm to work efficiently :( > > Thanks in advance, I know that this is a little off topic but I need help > immediately to get this straightened out. Using Gmail + Thunderbird > > > Regards, > Joel > > -- > Joel Madero > LibO QA Volunteer > jmadero@gmail.com > > > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: is 'make check' supposed to work on ~master ?
Well, I re-tried 'make build ; make check' with './configure --disable-online-update'. But I run into the the following : (Maybe I should leave this alone for now ...) [build CUT] sw_subsequent_ooxmlimport ods Test xls Test xlsx Test csv Test ==5755== Conditional jump or move depends on uninitialised value(s) ==5755==at 0xE43D5E3: std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_lower_bound(std::_Rb_tree_node >*, std::_Rb_tree_node >*, unsigned long const&) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsvllo.so) ==5755==by 0xE437F69: std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::find(unsigned long const&) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsvllo.so) ==5755==by 0xE432D2A: std::map, std::allocator > >::find(unsigned long const&) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsvllo.so) ==5755==by 0xE4165E7: SvNumberFormatter::GetFormatEntry(unsigned long) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsvllo.so) ==5755==by 0xE40BD31: SvNumberFormatter::IsNumberFormat(rtl::OUString const&, unsigned long&, double&) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsvllo.so) ==5755==by 0xA532CC0: ScColumn::SetString(long, short, String const&, formula::FormulaGrammar::AddressConvention, ScSetStringParam*) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsclo.so) ==5755==by 0xA967AD1: ScTable::SetString(short, long, short, String const&, ScSetStringParam*) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsclo.so) ==5755==by 0xA67C26C: ScDocument::SetString(short, long, short, rtl::OUString const&, ScSetStringParam*) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsclo.so) ==5755==by 0xB45C020: lcl_PutString(ScDocument*, short, long, short, String const&, unsigned char, SvNumberFormatter*, bool, utl::TransliterationWrapper&, CalendarWrapper&, utl::TransliterationWrapper*, CalendarWrapper*) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsclo.so) ==5755==by 0xB45EE90: ScImportExport::ExtText2Doc(SvStream&) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsclo.so) ==5755==by 0xB4544D3: ScImportExport::ImportStream(SvStream&, String const&, unsigned long) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsclo.so) ==5755==by 0xB3415CB: ScDocShell::ConvertFrom(SfxMedium&) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsclo.so) ==5755==by 0xD8F5355: SfxObjectShell::DoLoad(SfxMedium*) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsfxlo.so) ==5755==by 0x65EF318: ScFiltersTest::load(rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, unsigned int, unsigned int, unsigned int) (in /usr/local/src/libreoffice/workdir/unxlngi6.pro/LinkTarget/CppunitTest/libtest_sc_subsequent_filters_test.so) ==5755==by 0x662804E: ScFiltersTest::testBrokenQuotesCSV() (in /usr/local/src/libreoffice/workdir/unxlngi6.pro/LinkTarget/CppunitTest/libtest_sc_subsequent_filters_test.so) ==5755==by 0x666F4D8: CppUnit::TestCaller::runTest() (in /usr/local/src/libreoffice/workdir/unxlngi6.pro/LinkTarget/CppunitTest/libtest_sc_subsequent_filters_test.so) ==5755==by 0x4B895E10: CppUnit::TestCaseMethodFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4C337CD: (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/unobootstrapprotector.so) ==5755==by 0x4B8930F1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4012ED5: (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (in /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/unoexceptionprotector.so) ==5755==by 0x4B8930F1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4B88BDB9: CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4B8930F1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4B892DC8: CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4B89C5DD: CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::string const&) (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4B895AC7: CppUnit::TestCase::run(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4B896223: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4B89614B: CppUnit::TestComposite::run(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.1.0.0) ==5755==by 0x4B896223:
Re: is 'make check' supposed to work on ~master ?
On Thu, Dec 13, 2012 at 10:35 AM, Stephan Bergmann wrote: > On 12/12/2012 06:36 PM, John Smith wrote: >> >> Im trying to run 'make check' at toplevel on ~master. It fails for me >> at this point (soffice.bin crashes) : >> >> make >> /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/comphelper_complex/done > > > Is that crash reproducible for you? The backtrace doesn't give much of a > clue to why it fails, so if it is reproducible running under Valgrind might > help. > > In general, the online update mechanism spawns threads that it doesn't > properly join again before exit, which is a notorious problem with tests > (that often run quickly enough to terminate soffice.bin while the online > update check is still in progress), so I recommend to configure with > --disable-online-update (which is the implicit default on Linux anyway, > though). But the backtrace here doesn't look like it is caused by that > problem anyway. > It's pretty much reproducable for me: I re-tried make a few times. Ill retry with ./configure --disable-online-update && make build && make check, and see if it still fails. - John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
is 'make check' supposed to work on ~master ?
Hi, Im trying to run 'make check' at toplevel on ~master. It fails for me at this point (soffice.bin crashes) : make /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/comphelper_complex/done Is that 'supposed to work', or should I expect failure(s) ? - John Smith -- stacktrace -- It seems like soffice.bin crashed during the test excution! Found a core dump at /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/comphelper_complex/user/core.23956 Stacktrace: [New LWP 23956] [New LWP 23957] [New LWP 23960] warning: the debug information found in "/usr/lib/debug/usr/lib/libstdc++.so.6.0.17.debug" does not match "/lib/libstdc++.so.6" (CRC mismatch). warning: the debug information found in "/usr/lib/debug//usr/lib/libstdc++.so.6.0.17.debug" does not match "/lib/libstdc++.so.6" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/usr/lib//libstdc++.so.6.0.17.debug" does not match "/lib/libstdc++.so.6" (CRC mismatch). [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/soffice'. Program terminated with signal 11, Segmentation fault. #0 0x46ebbcab in _int_free (av=av@entry=0x46ff2420, p=0x9949118, have_lock=have_lock@entry=1) at malloc.c:4103 4103unlink(av, nextchunk, bck, fwd); warning: File "/usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libuno_sal.so.3-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py". warning: File "/usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libuno_cppu.so.3-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py". warning: File "/usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libsvllo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py". warning: File "/usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libtllo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py". Thread 3 (Thread 0xadc6cb40 (LWP 23960)): #0 0xb77ea424 in __kernel_vsyscall () #1 0x46f3a968 in accept () at ../sysdeps/unix/sysv/linux/i386/socket.S:97 #2 0xb76e8b46 in osl_acceptPipe () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/../ure-link/lib/libuno_sal.so.3 #3 0xb75c6492 in osl::Pipe::accept(osl::StreamPipe&) () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/libsofficeapp.so #4 0xb75beccb in desktop::OfficeIPCThread::execute() () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/libsofficeapp.so #5 0xb6a99a2f in salhelper::Thread::run() () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/../ure-link/lib/libuno_salhelpergcc3.so.3 #6 0xb6a9a21a in threadFunc () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/../ure-link/lib/libuno_salhelpergcc3.so.3 #7 0xb76f8525 in osl_thread_start_Impl () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/../ure-link/lib/libuno_sal.so.3 #8 0x46ffeadf in start_thread (arg=0xadc6cb40) at pthread_create.c:309 #9 0x46f3954e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 Thread 2 (Thread 0xb00fab40 (LWP 23957)): #0 0xb77ea424 in __kernel_vsyscall () #1 0x470024d4 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:238 #2 0x46f479a4 in __pthread_cond_timedwait (cond=0xb77cdaa0, mutex=0xb77cd940, abstime=0xb00f72e0) at forward.c:152 #3 0xb7711090 in rtl_cache_wsupdate_wait(unsigned int) () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/../ure-link/lib/libuno_sal.so.3 #4 0xb771159d in rtl_cache_wsupdate_all(void*) () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/../ure-link/lib/libuno_sal.so.3 #5 0x46ffeadf in start_thread (arg=0xb00fab40) at pthread_create.c:309 #6 0x46f3954e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 Thread 1 (Thread 0xb02ff700 (LWP 23956)): #0 0x46ebbcab in _int_free (av=av@entry=0x46ff2420, p=0x9949118, have_lock=have_lock@entry=1) at malloc.c:4103 #1 0x46ebe180 in free_check (mem=0x9949180, caller=0xb77132f7) at hooks.c:259 #2 0x46ebf9e1 in __GI___libc_free (mem=0x9949180) at malloc.c:2964 #3 0xb77132f7 in rtl_freeMemory_SYSTEM(void*) () from /usr/local/src/libreoffice/solver/unxlngi6.pro/installation/opt/program/../ure-link/lib/libuno_sal.so.
Re: undefined reference to `__gcov_init' when using FLAGS+='-fprofile-arcs -ftest-coverage'
On Wed, Dec 12, 2012 at 12:28 PM, Michael Stahl wrote:
>
> but apparently LDFLAGS don't
>
> hmmm... you could try editing these and adding your options there:
>
> solenv/inc/unxgcc.mk:LINKFLAGSSHLGUI= -shared
> solenv/inc/unxgcc.mk:LINKFLAGSSHLCUI= -shared
>
This works, by the way, for setup_native. But even after editing those
files the same behavior (LDFLAGS not set) appears when building odk.
And I cant seem to be able to figure out what makefile to hack to fix
it. Of course I can just do './configure --disable-odk'...
# LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage'
CXXFLAGS+='-fprofile-arcs -ftest-coverage' CPPFLAGS+='-fprofile-arcs
-ftest-coverage' make odk VERBOSE=t
make -r -f /usr/local/src/libreoffice/Makefile.top odk
make[1]: Entering directory `/usr/local/src/libreoffice'
cd odk && unset MAKEFLAGS &&
/usr/local/src/libreoffice/solenv/bin/build.pl -P2 -- -P2
=
(1/1) Building module odk
=
Entering /usr/local/src/libreoffice/odk/inc
Entering /usr/local/src/libreoffice/odk/pack/unzip_udk
Entering /usr/local/src/libreoffice/odk/source/unowinreg/win
Entering /usr/local/src/libreoffice/odk/source/com/sun/star/lib/loader
/bin/cp
/usr/local/src/libreoffice/src/185d60944ea767075d27247c3162b3bc-unowinreg.dll
../../../unxlngi6.pro/bin/unowinreg.dll
Entering /usr/local/src/libreoffice/odk/source/unoapploader/unx
Making:com_sun_star_lib_loader.dpj
rm -f ../../../../../../unxlngi6.pro/misc/com_sun_star_lib_loader_dummy.java
rm -f ../../../../../../unxlngi6.pro/misc/com_sun_star_lib_loader_dummy.java
Compiling: odk/source/unoapploader/unx/unoapploader.c
rm -f ../../../../../../unxlngi6.pro/misc/com_sun_star_lib_loader_dummy.java
gcc -fprofile-arcs -ftest-coverage -fmessage-length=0 -c -Os -I.
-I../../../unxlngi6.pro/inc/unoapploader -I../inc -I../../../inc
-I../../../unx/inc -I../../../unxlngi6.pro/inc -I.
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/external
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc
-I/usr/local/src/libreoffice/solenv/inc
-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5/include
-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5/include/linux
-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5/include/native_threads/include
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/udkapi
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/offapi
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/oovbaapi -I.
-I../../../res -I. -pipe -mtune=pentiumpro -fprofile-arcs
-ftest-coverage -fmessage-length=0 -c -Os -Wall -Wextra
-Wendif-labels -Wdeclaration-after-statement -DLINUX -DUNX -DGCC
-DINTEL -DGLIBC=2 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR
-D_USE_NAMESPACE=1 -DHAVE_GCC_VISIBILITY_FEATURE -DX86 -D__DMAKE
-DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.7.2
-DSUPD=410 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE
-DHAVE_THREADSAFE_STATICS -DRTL_USING -DSOLAR_JAVA -o
../../../unxlngi6.pro/obj/unoapploader.o unoapploader.c
: &&
LD_LIBRARY_PATH=/usr/local/src/libreoffice/solver/unxlngi6.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
/usr/local/src/libreoffice/solver/unxlngi6.pro/bin/makedepend
@/tmp/mkfV0F2B > ../../../unxlngi6.pro/misc/o_unoapploader.dpcc
rm -f ../../../../../../unxlngi6.pro/misc/com_sun_star_lib_loader_dummy.java
/bin/javac -source 1.5 -target 1.5 -classpath
".:../../../../../../unxlngi6.pro/class:" -d
../../../../../../unxlngi6.pro/class @/tmp/mkIqMQRk
Making:unoapploader
gcc -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs
-Wl,-Bsymbolic-functions -Wl,--dynamic-list-cpp-new
-Wl,--dynamic-list-cpp-typeinfo -Wl,--hash-style=gnu
-Wl,-export-dynamic
-Wl,-rpath-link,../../../unxlngi6.pro/lib:/usr/local/src/libreoffice/solver/unxlngi6.pro/lib:/lib:/usr/lib
-L../../../unxlngi6.pro/lib -L../lib
-L/usr/local/src/libreoffice/solenv/unxlngi6/lib
-L/usr/local/src/libreoffice/solver/unxlngi6.pro/lib
-L/usr/local/src/libreoffice/solenv/unxlngi6/lib
../../../unxlngi6.pro/obj/unoapploader.o \
-lfindsofficepath -ldl -o ../../../unxlngi6.pro/bin/unoapploader
../../../unxlngi6.pro/obj/unoapploader.o:(.data+0x14): undefined
reference to `__gcov_merge_add'
../../../unxlngi6.pro/obj/unoapploader.o: In function `main':
unoapploader.c:(.text.startup+0x56f): undefined reference to `__gcov_execvp'
../../../unxlngi6.pro/obj/unoapploader.o: In function
`_GLOBAL__sub_I_65535_0_SEPARATOR':
unoapploader.c:(.text.startup+0x5c7): undefined reference to `__gcov_init'
/usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libfindsofficepath.a(findsofficepath.o):
In function `_GLOBAL__sub_I_65535_0_findsofficepath.c':
findsofficepath.c:(.text+0x429): undefined reference to `__gcov_init'
/usr/local/src/libreoffice/solver/unxlngi6.pro/lib/libfindsofficepath.a(findsofficepath.o):(.data.rel+0x10):
undefined reference to `__gcov_merge_add'
collect2: error: ld returned 1 exit status
dmake: Error code 1, while making '../../../unxlngi6.pro/bin/unoapploader'
---
Re: undefined reference to `__gcov_init' when using FLAGS+='-fprofile-arcs -ftest-coverage'
On Wed, Dec 12, 2012 at 12:28 PM, Michael Stahl wrote: > > well obviously check that the flags you want to add are actually on the > command line... > Thank you so much for your time and patience. Yes, I could have checked if these options ended up on the command line. I was wrongly assuming you meant 'check if/how the dmake system is still used', and I didnt know how to look for that. > > of course the best would be to convert the module to the new build > system and send a patch :) > I would if I could. But as you can clearly see, I would need some serious hand holding for that. I can add a bit about dmake not supporting LDFLAGS this way (and that the new gbuild system does) to the wiki page describing how to generate the lcov reports. Thanks, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: undefined reference to `__gcov_init' when using FLAGS+='-fprofile-arcs -ftest-coverage'
On Wed, Dec 12, 2012 at 11:36 AM, Michael Stahl wrote:
>
> setup_native still uses the old dmake based build system, most likely
> that does not support those *FLAGS variables. you can check with "make
> setup_native VERBOSE=t" if that stuff is actually used.
>
Thanks. But I have no idea what to look for in the output when using VERBOSE=t.
:(
This is the output I get with make setup_native VERBOSE=t :
# LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage'
CXXFLAGS+='-fprofile-arcs -ftest-coverage' CPPFLAGS+='-fprofile-arcs
-ftest-coverage' make setup_native VERBOSE=t
make -r -f /usr/local/src/libreoffice/Makefile.top setup_native
make[1]: Entering directory `/usr/local/src/libreoffice'
cd setup_native && unset MAKEFLAGS &&
/usr/local/src/libreoffice/solenv/bin/build.pl -P2 -- -P2
=
(1/1) Building module setup_native
=
Entering /usr/local/src/libreoffice/setup_native/source/mac
Entering /usr/local/src/libreoffice/setup_native/scripts/source
Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/makecab
Making:all_getuid.dpslo
No winegcc present, not building makecab...
Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/msidb
Compiling: setup_native/scripts/source/getuid.c
gcc -fprofile-arcs -ftest-coverage -fmessage-length=0 -c -Os
-D_GNU_SOURCE -I. -I../../unxlngi6.pro/inc/getuid -I../inc -I../../inc
-I../../unx/inc -I../../unxlngi6.pro/inc -I.
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/external
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc
-I/usr/local/src/libreoffice/solenv/inc
-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5/include
-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5/include/linux
-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5/include/native_threads/include
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/udkapi
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/offapi
-I/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/oovbaapi -I.
-I../../res -I. -pipe -mtune=pentiumpro -fprofile-arcs -ftest-coverage
-fmessage-length=0 -c -Os -D_GNU_SOURCE -Wall -Wextra
-Wendif-labels -Wdeclaration-after-statement -fpic -DLINUX -DUNX -DGCC
-DINTEL -DGLIBC=2 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR
-D_USE_NAMESPACE=1 -DHAVE_GCC_VISIBILITY_FEATURE -DX86 -D__DMAKE
-DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.7.2
-DSUPD=410 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE
-DHAVE_THREADSAFE_STATICS -DRTL_USING -DSOLAR_JAVA -o
../../unxlngi6.pro/slo/getuid.o getuid.c
: &&
LD_LIBRARY_PATH=/usr/local/src/libreoffice/solver/unxlngi6.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
/usr/local/src/libreoffice/solver/unxlngi6.pro/bin/makedepend
@/tmp/mkCa8M3B > ../../unxlngi6.pro/misc/s_getuid.dpcc
No winegcc present, not building msidb...
Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/msiinfo
-
SHL1FILTERFILE not set!
-
No winegcc present, not building msiinfo...
dummy file to keep the dependencies for later use.
rm -f ../../unxlngi6.pro/lib/check_getuid.so
mv ../../unxlngi6.pro/lib/getuid.so ../../unxlngi6.pro/lib/check_getuid.so
/usr/local/src/libreoffice/solenv/bin/checkdll.sh
-L../../unxlngi6.pro/lib
-L/usr/local/src/libreoffice/solver/unxlngi6.pro/lib
../../unxlngi6.pro/lib/check_getuid.so
Making:getuid.so
Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/msimsp
gcc -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs
-Wl,-Bsymbolic-functions -Wl,--dynamic-list-cpp-new
-Wl,--dynamic-list-cpp-typeinfo -Wl,--hash-style=gnu -Wl,-z,origin
-Wl,-rpath,'$ORIGIN:$ORIGIN/../ure-link/lib',--enable-new-dtags
-shared -L../../unxlngi6.pro/lib -L../lib
-L/usr/local/src/libreoffice/solenv/unxlngi6/lib
-L/usr/local/src/libreoffice/solver/unxlngi6.pro/lib
-L/usr/local/src/libreoffice/solenv/unxlngi6/lib
../../unxlngi6.pro/slo/getuid.o -o ../../unxlngi6.pro/lib/getuid.so
-ldl -Wl,--as-needed -ldl -lpthread -lm -Wl,--no-as-needed
No winegcc present, not building msimsp...
Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/msitran
../../unxlngi6.pro/slo/getuid.o: In function `_GLOBAL__sub_I_65535_0_getuid.c':
getuid.c:(.text.startup+0x1a): undefined reference to `__gcov_init'
../../unxlngi6.pro/slo/getuid.o:(.data.rel+0x10): undefined reference
to `__gcov_merge_add'
No winegcc present, not building msitran...
collect2: error: ld returned 1 exit status
dmake: Error code 1, while making '../../unxlngi6.pro/lib/getuid.so'
---
Oh dear - something failed during the build - sorry !
For more help with debugging build errors, please see the section in:
http://wiki.documentfoundation.org/Development
internal build errors:
ERROR: error 65280 occurred while making
/usr/local/src/libreoffice/setup_native/scripts/source
it seems that the error is inside '', please re-run build
inside this module to isolate
Re: undefined reference to `__gcov_init' when using FLAGS+='-fprofile-arcs -ftest-coverage'
On Wed, Dec 12, 2012 at 3:04 AM, Caolán McNamara wrote: > On Tue, 2012-12-11 at 21:50 +0100, John Smith wrote: >> But I still get this error message (in 'make setup_native') >> >> undefined reference to `__gcov_init' >> >> Does anyone have an idea of what might be going on here ? > > Does > - LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage' > + LDFLAGS+='-fprofile-arcs -lgcov' CFLAGS+='-fprofile-arcs > -ftest-coverage' > > make any difference ? > Sadly, explicitly adding -glcov (-fprofile-arcs implies -lgcov) does not make a difference. I still get this : Making:getuid.so No winegcc present, not building msiinfo... Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/msimsp ../../unxlngi6.pro/slo/getuid.o: In function `_GLOBAL__sub_I_65535_0_getuid.c': getuid.c:(.text.startup+0x1a): undefined reference to `__gcov_init' ../../unxlngi6.pro/slo/getuid.o:(.data.rel+0x10): undefined reference to `__gcov_merge_add' collect2: error: ld returned 1 exit status dmake: Error code 1, while making '../../unxlngi6.pro/lib/getuid.so' --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development No winegcc present, not building msimsp... internal build errors: ERROR: error 65280 occurred while making /usr/local/src/libreoffice/setup_native/scripts/source it seems that the error is inside '', please re-run build inside this module to isolate the error and/or test your fix. --- To rebuild a specific module: make .clean # optional make when the problem is isolated and fixed, re-run 'make' make[1]: *** [setup_native] Error 1 make[1]: Leaving directory `/usr/local/src/libreoffice' make: *** [setup_native] Error 2 [root@localhost libreoffice]# ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
undefined reference to `__gcov_init' when using FLAGS+='-fprofile-arcs -ftest-coverage'
Hi, Im trying to build libreoffice for using gcov/loc, so Ive set: LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage' CXXFLAGS+='-fprofile-arcs -ftest-coverage' \ CPPFLAGS+='-fprofile-arcs -ftest-coverage' But I still get this error message (in 'make setup_native') undefined reference to `__gcov_init' Does anyone have an idea of what might be going on here ? Regards, John Smith The output from make is : # LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage' CXXFLAGS+='-fprofile-arcs -ftest-coverage' CPPFLAGS+='-fprofile-arcs -ftest-coverage' make setup_native make -r -f /usr/local/src/libreoffice/Makefile.top setup_native make[1]: Entering directory `/usr/local/src/libreoffice' cd setup_native && unset MAKEFLAGS && /usr/local/src/libreoffice/solenv/bin/build.pl -P2 -- -P2 = (1/1) Building module setup_native = Entering /usr/local/src/libreoffice/setup_native/scripts/source Entering /usr/local/src/libreoffice/setup_native/source/mac Making:getuid.so Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/makecab No winegcc present, not building makecab... Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/msidb ../../unxlngi6.pro/slo/getuid.o: In function `_GLOBAL__sub_I_65535_0_getuid.c': getuid.c:(.text.startup+0x1a): undefined reference to `__gcov_init' ../../unxlngi6.pro/slo/getuid.o:(.data.rel+0x10): undefined reference to `__gcov_merge_add' No winegcc present, not building msidb... collect2: error: ld returned 1 exit status dmake: Error code 1, while making '../../unxlngi6.pro/lib/getuid.so' Entering /usr/local/src/libreoffice/setup_native/source/win32/wintools/msiinfo --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development No winegcc present, not building msiinfo... internal build errors: ERROR: error 65280 occurred while making /usr/local/src/libreoffice/setup_native/scripts/source it seems that the error is inside '', please re-run build inside this module to isolate the error and/or test your fix. --- To rebuild a specific module: make .clean # optional make when the problem is isolated and fixed, re-run 'make' make[1]: *** [setup_native] Error 1 make[1]: Leaving directory `/usr/local/src/libreoffice' make: *** [setup_native] Error 2 [root@localhost libreoffice]# ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: liborcus sources website
Hi, On Tue, Dec 11, 2012 at 3:04 PM, Rene Engelhard wrote: > > And the above downloaded piece won't helpyou at all if you use > --with-system-orcus (which you obviously do otherwise it wouldn't check > for it) as in that case you obviously need a orcus (and a liborcus-0.4.pc) > _already_ on your system. > Oh, wait... Im using '--with-system-libs'. I forgot. Oops. Adding '--with-system-orcus=no' fixes it. My mistake. Thanks for the help. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: liborcus sources website
Hi, On Tue, Dec 11, 2012 at 2:13 PM, Stephan van den Akker wrote: > Hi John, > > If I recall correctly, during "make" the liborcus source will be pulled in > from a Libre Office server. Just make sure you have an internet connection. > Thanks. 'make' does download a version of it, but it looks like it's 0.3. make output: 2012-12-11 15:44:27 (3.05 MB/s) - `./8755aac23317494a9028569374dc87b2-liborcus_0.3.0.tar.bz2' saved [1373518/1373518] My configure breaks because it cant find 0.4 checking for ORCUS... no configure: error: Package requirements (liborcus-0.4 >= 0.3.0) were not met: No package 'liborcus-0.4' found - John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
liborcus sources website
Hi, I see a LibreOffice build has a pre-req for 'liborcus-0.4'. However, my Fedora system has no packages for that. Does anyone know what the website of that is, so I can download and install the sources ? I tried a quick google, but couldnt find it. Thanks. Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: static clang source code analysis (Code Review Requested)
Hi, So now that people know how to generate these reports, lets hope they are going to be put to good use ! ;) - John Smith. On Mon, Dec 10, 2012 at 9:19 AM, Miklos Vajna wrote: > Hi John, > > On Fri, Dec 07, 2012 at 04:41:48PM +0100, John Smith > wrote: >> The clang analyzer how-to is here : >> http://wiki.documentfoundation.org/Development/Clang > > Thanks a lot for both! > > Miklos ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: static clang source code analysis (Code Review Requested)
Hi, The clang analyzer how-to is here : http://wiki.documentfoundation.org/Development/Clang Regards, John Smith. On Fri, Dec 7, 2012 at 11:08 AM, John Smith wrote: > Hi, > > > For the lcov reports, I put the following in the wiki: > http://wiki.documentfoundation.org/Development/Lcov > Feel free to try it out and edit it as you see fit. > > Regards, > > > John Smith. > > > > On Wed, Dec 5, 2012 at 5:33 PM, Miklos Vajna wrote: >> On Wed, Dec 05, 2012 at 04:15:45PM +0100, John Smith >> wrote: >>> Sure, I can put short tutorials for generating both reports on the >>> wiki. How do I get a wiki account, and where on the wiki should I put >>> them ? >> >> Creating a wiki account: >> >> https://wiki.documentfoundation.org/index.php?title=Special:UserLogin&type=signup >> >> I would create a page called >> http://wiki.documentfoundation.org/Development/Something, and link it >> from the Development page. >> >> Alternatively, just create two scripts that do the clang analysis / lcov >> report, and add it to git: >> >> http://wiki.documentfoundation.org/Development#Preparing_patches >> >> Thanks, >> >> Miklos >> >> ___ >> LibreOffice mailing list >> LibreOffice@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/libreoffice >> ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: static clang source code analysis (Code Review Requested)
Hi, For the lcov reports, I put the following in the wiki: http://wiki.documentfoundation.org/Development/Lcov Feel free to try it out and edit it as you see fit. Regards, John Smith. On Wed, Dec 5, 2012 at 5:33 PM, Miklos Vajna wrote: > On Wed, Dec 05, 2012 at 04:15:45PM +0100, John Smith > wrote: >> Sure, I can put short tutorials for generating both reports on the >> wiki. How do I get a wiki account, and where on the wiki should I put >> them ? > > Creating a wiki account: > > https://wiki.documentfoundation.org/index.php?title=Special:UserLogin&type=signup > > I would create a page called > http://wiki.documentfoundation.org/Development/Something, and link it > from the Development page. > > Alternatively, just create two scripts that do the clang analysis / lcov > report, and add it to git: > > http://wiki.documentfoundation.org/Development#Preparing_patches > > Thanks, > > Miklos > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: static clang source code analysis (Code Review Requested)
> Miklos Vajna vmiklos at suse.cz > > Hi John, > > On Mon, Nov 05, 2012 at 02:45:22AM +0100, John Smith > wrote: > > Here's a clang static source code analysis of the latest git sources : > > > > http://dev-builds.libreoffice.org/clang_reports/master~2012-11-04_17.27.13/ > > I know this is a clang report and not the lcov one, but -- can you > please put up the commands you use to generate these reports to the > wiki, or (maybe even better) add two scripts like > bin/generate-lcov-report and bin/generate-clang-report, so that > developers can easily create them, too? > Sorry for the late response. Sure, I can put short tutorials for generating both reports on the wiki. How do I get a wiki account, and where on the wiki should I put them ? - John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
static clang source code analysis (Code Review Requested)
Hi, Here's a clang static source code analysis of the latest git sources : http://dev-builds.libreoffice.org/clang_reports/master~2012-11-04_17.27.13/ Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: --headless broken with --enable-headless
On Fri, Sep 7, 2012 at 8:33 PM, Riccardo Magliocchetti wrote: > Does anyone can give it a try with a build without --enable-headless please? Urm. Do *what* exactly, without --enable-headless ? - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] How Can I Provide More Info For Developers
On Fri, Sep 7, 2012 at 9:59 PM, Joel Madero wrote: > This isn't for end-users, it's for QA team..and it's our job to do as > much as possible to help the developers. I know when I'm doing the > development side I appreciate whatever previous info users and QA can > provide. It's maximizing the efficiency of our abilitieslimited # of > developers means we should be using their time wisely, not running > backtraces that someone with 1/10th of their computer programming skills > could manage just fine. > > Best Regards, > Joel > Well, like I said: I guess it all depends on who your target audience is. Just keep in mind who that is, and what their expected skill set is, and adjust your procedures to that. IMHO. - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] How Can I Provide More Info For Developers
On Fri, Sep 7, 2012 at 9:49 PM, Joel Madero wrote: > I'll bring this up at our next conference call and see if there is a > possible solution. > > > Best Regards, > Joel > > May I humbly note that I personally feel that developers should be able to produce their own backtraces, given a solid reproducible test-case in the bug report ? Perhaps effort would be better spend on: 1.) teaching end-users how to provide a reproducible test case in a bug report 2.) teaching devs on how to produce backtraces instead of: 1.) teaching end-users how to install symbol binaries and backtrace them on their platform ? Just my 2$ - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] How Can I Provide More Info For Developers
On Fri, Sep 7, 2012 at 9:42 PM, Joel Madero wrote: > > > Sounds good, but I agree with John that better instructions are needed. I'm > working on a new triage page and hopefully in there we can get someone to > contribute incredibly precise, easy for noobs, instructions for every type > of backtrace/debug. Right now they are really written by experts for experts > (IMO). I would backtrace much more frequently if I could follow the > instructions on how to do it. Every time I feel like I have to go on IRC and > ask 100 questions. > > > > > > > I don't think we have enough people packaging to make pre-built binaries for > everyone. Plus, these are huge, my install is 22 gigs with all symbols on, > not very good for packaging purposes. > I guess it all depends on who your target audience is. If you really want end-users (libre office users) to provide backtraces, you really need to make the threshold for doing that as low as possible. I dont think it is reasonable to have end-users compile source code for themselves; especially on windows, where it requires msvc or cygwin to do so. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] How Can I Provide More Info For Developers
On Fri, Sep 7, 2012 at 7:24 PM, Michael Meeks wrote: > Hi John, > > You can always make it easier for a developer to solve - and the > easier > it is, the more likely it is to get solved quickly. Ways to do that are: > > * getting a stack-trace with full debugging symbols > > * running valgrind with full debugging symbols and > attaching a trace. > If this is the case, maybe pre-build binaries with full debugging symbols should be made available for download (more) easily: both for releases and daily master builds ? Also, a 'howto' on how to do this (on linux, with gdb, on windows, with windbg ?) would be nice to have ? - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: How Can I Provide More Info For Developers
On Fri, Sep 7, 2012 at 6:59 PM, Joel Madero wrote: > Wrong Bug, dammit, my bad. Here is the proper one, attachment is there and > functioning, I had 5 open FDO tabs in FF and picked the wrong one. > > https://bugs.freedesktop.org/show_bug.cgi?id=48569 > > My apologies > > Joel > Maybe im just dumb, but: Once you have provided a reliable and reproducible test case (in this case, download the odt file attached to the report and save it as docx in libreoffice), is there still a need to provide further info at all ? The person tackling the bug can get all the info required on his/her own system, then ? Just my 2$. - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: How Can I Provide More Info For Developers
On Fri, Sep 7, 2012 at 6:38 PM, Joel Madero wrote: > I don't see that helping much, as the developer who takes this one can > quickly do this themselves. A working doc only takes 2 seconds to make. > > Best Regards, > Joel > Another random thought then: Is there a way to reproduce the issue that doesnt require the installation of Lotus Domino ? - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: How Can I Provide More Info For Developers
On Fri, Sep 7, 2012 at 6:11 PM, Joel Madero wrote: > Hi All, > > Came across this bug FDO#45570 and I've already nominated as a most annoying > bug but I think that devs might appreciate me getting some kind of a log or > something together for the crash. What type of log should I create and how > do I go about doing this (basic steps, my knowledge of terminology is still > in the first stages :) ). Thanks everyone > > > > Best Regards, > Joel > Just some random thoughts here: What happens when you create a 'working document', thats been opened and saved in Msoffice or OpenOffice, and then try to open that saved doc in LibreOffice ? Does the issue still appear ? Also, would it be helpful to attach such a document to the bug report for troubleshooting purposes ? - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?
On Thu, Sep 6, 2012 at 2:53 PM, Michael Meeks wrote:
>
> On Thu, 2012-09-06 at 13:15 +0200, John Smith wrote:
>> Alright, let me see if I understand this one correctly first. You
>> basically want people to be able to find out what gets "#define" 'd in
>> what rc files ? So for example, you want people to search for
>> "FL_RECORD" to discover that that gets defined in
>> './sw/source/ui/envelp/mailmrge.hrc" ?
>
> Nope it's worse than that; we want to go from "Export" to:
>
> String STR_PDF_EXPORT
> {
> Text[ en-US ] = "E~xport";
> };
>
I still dont understand. Something to do with my lack of understanding
C++, I guess. Feel free to ignore or answer as you see fit; I doubt
ill be able to do what is needed at this point anyway. So what would
be needed as input, and what would be the output ?
You want people to be able to enter "Records" as input, and have it
output this :
FixedLine FL_RECORD
{
Pos = MAP_APPFONT ( 6 , 86 ) ;
Size = MAP_APPFONT ( 126 , 8 ) ;
Text [ en-US ] = "Records" ;
};
as it is listed in "./sw/source/ui/envelp/mailmrge.src" ?
Or, more strictly: have people enter "Drawing View", to output
String SID_SD_A11Y_D_DRAWVIEW_N
{
Text [ en-US ] = "Drawing View";
};
as listed in "./sd/source/ui/accessibility/accessibility.src", but
*only* for the cases where it says exactly "String ALL_CAPS_HERE",
*and* the only thing between the curly braces is :
Text [ en-US ] = "Drawing View"
?
- John.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?
On Wed, Sep 5, 2012 at 1:15 PM, Michael Meeks wrote:
>
>
> Of course, if you really don't want to look into / learn that; I had
> another idea that'd be great to get implemented:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=39439
>
Alright, let me see if I understand this one correctly first. You
basically want people to be able to find out what gets "#define" 'd in
what rc files ? So for example, you want people to search for
"FL_RECORD" to discover that that gets defined in
'./sw/source/ui/envelp/mailmrge.hrc" ?
If that is true, I guess I could work on a shell script that does
something like this :
find /usr/local/src/libreoffice -name \*.\?rc -exec grep "FL_RECORD" {} \;
of course, those searches will take a while and will have to be
executed on the Linux cmd prompt, so that will be no good for Windows
users.
But again, I feel things similar to this must have been done before
elsewhere. Arent there program around that tell you what gets #define
'd in which /usr/include header files ? Dont some IDE's even do stuff
like that for you automagically ? Surely it would be far easier to
modify such logic to work on those *.?rc files than to start from
scratch completely ?
- John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?
On Wed, Sep 5, 2012 at 1:15 PM, Michael Meeks wrote: > > Well - it's worth creating an easy hack so people can look at this > stuff; also - I'm impressed by your work - I think you underestimate > your ability to learn C++ :-) > Well I did just order O'Reilly's 'Head First Programming: A Learner's Guide to Programming Using the Python Language', so perhaps Ill finally get myself to learn how to code now. Ive been putting that off for years now, as I really never did find a good book for complete newbees that I was able to learn C from. Also - the neat HTML reports are what makes it look impressive; remember I basically didnt have to do much more than compile the sources and execute some scripts. > > Of course, if you really don't want to look into / learn that; I had > another idea that'd be great to get implemented: > > https://bugs.freedesktop.org/show_bug.cgi?id=39439 > > That is a webby / scripty / build-a-database-from-the-code type > scripting task that would really help people get stuck into coding more > quickly I think - any bites ? :-) > Oof... You call that one an 'EasyHack' ? Surely there must be some software out there already that enables you to efficiently search/browse a codebase and/or API / etc ? For example, doesnt 'doxygen' do what you want here ? - John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?
On Wed, Sep 5, 2012 at 10:43 AM, Noel Grandin wrote: > How about producing some patches to fix issues you found? > I wish I could. Im just a unix sys admin, and not a developer. Writing shell scripts is no problem, but I doubt ill be coding C++ anytime soon. :( Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?
Hi, I was wondering, now that there are initial reports for both code coverage and statistic analysis, what the next step could be ? For example, are people interested in mini-HOWTO's on how to (re-)produce the reports ? Something else entirely ? Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
Hi. So now that we have a coverage report, does that mean that this bug/issue can be closed ? Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
On Mon, Aug 27, 2012 at 9:10 AM, Stephan Bergmann wrote: > > (at least for the given case of our LO code base, which is not too heavily > loaded with dedicated tests to begin with). > Well at the moment there may not be a lot of testcases. But I get the impression that the whole reason for adding test coverage in the 1st place, is that (much) more tests are intended to be added in the future for covering the code that isnt tested yet ? And if that is the case, wouldnt it make more sense to cleanly separate 'building your project' and 'testing your project' ? I dont get the impression that everyone that compiles the code will be interested in all checks being executed, especially once there are more tests. For the future, it might make more sense if 'make build' (or something similar) only compiles the code without running the tests, and that the tests only get executed if 'make check' is run ? Just my 2$ Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'make check' failure
Well, I commented out 'sc.ScAccessiblePageHeaderArea' from 'sc/qa/unoapi/sc.sce', but then the following error occurs: Regards, John Smith. LOG> Log started 26.07.2012 - 20:57:32 Creating: sc.ScAccessiblePreviewHeaderCell LOG> Log started 26.07.2012 - 20:57:32 LOG> creating a Spreadsheet document LOG> Getting spreadsheet LOG> Getting a cell from sheet Exception while getting Environment com.sun.star.lang.DisposedException: at com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:162) at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:128) at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:327) at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:296) at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:81) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:628) at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:141) at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:123) at $Proxy26.getAccessibleChild(Unknown Source) at util.AccessibilityTools.getAccessibleObjectForRole(AccessibilityTools.java:258) at util.AccessibilityTools.getAccessibleObjectForRole(AccessibilityTools.java:258) at util.AccessibilityTools.getAccessibleObjectForRole(AccessibilityTools.java:258) at util.AccessibilityTools.getAccessibleObjectForRole(AccessibilityTools.java:258) at util.AccessibilityTools.getAccessibleObjectForRole(AccessibilityTools.java:180) at mod._sc.ScAccessiblePreviewHeaderCell.createTestEnvironment(ScAccessiblePreviewHeaderCell.java:251) at lib.TestCase.getTestEnvironment(TestCase.java:123) at base.java_fat.getEnv(java_fat.java:453) at base.java_fat.executeTest(java_fat.java:208) at org.openoffice.Runner.run(Runner.java:234) at org.openoffice.test.UnoApiTest.test(UnoApiTest.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at org.junit.runner.JUnitCore.run(JUnitCore.java:136) at org.junit.runner.JUnitCore.run(JUnitCore.java:117) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) at org.junit.runner.JUnitCore.main(JUnitCore.java:45) LOG> disposing xSheetDoc No core dump at /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/sc_unoapi/user, to create core dumps (and stack traces) for crashed soffice instances,
Re: Bug 38840 - Adding coverage analysis to unit tests
Hi, I uploaded a new report that has the contents of '/usr/include/*' filtered out. Unfortunately, there still are files included that are located in '/usr/lib', but luckily that are only two files. I couldnt figure out how to filter out multiple directories in a single run of 'lcov', and the process really takes to long to do it in two passes just for those 2 files. Anyway, the report is located here: http://dev-builds.libreoffice.org/lcov_reports/ Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
On Fri, Aug 24, 2012 at 10:07 PM, Philipp Riemer wrote: > > As far as I learned in my Softw. Eng. courses, the main intent of this > type of code coverage is _not_ to show which parts are under test but > primarily to point out which parts are not tested at all so far. > Yes, of course. > > And as one can (now fortunately) see there are still quite some lines > of code that are not touched during the tests... But now we all have a > much better overview what parts are exactly missing tests -- which at > least from my perspective is much better than just guessing and gut > feeling! Thank you very much for all your great work so far, John! > Im still not convinced 'my' coverage report shows this *exactly*. > > Of course, in future, every bug should get a unit test (at best even > before starting to fix it) so that regressions are easier get caught > ;-) > In the ideal world, yes, of course. ;) > In addition, it would be also good, to have two reports: (1) with only > the unit test coverage and (2) one where all test, including > integration tests etc., were executed. Huh ? what ? Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
On Fri, Aug 24, 2012 at 5:28 PM, Stephan Bergmann wrote: > On 08/19/2012 09:14 PM, John Smith wrote: >> >> - First you run a plain make in the top level directory to build LO >> (with analysis stuff enabled). >> - then you create a 'baseline' with lcov (sort of create a 'before >> snapshot' of LO) >> - *then* you run all your tests (whatever they may be) >> - then you re-run lcov to create an 'after snapshot' >> - then you compare the 'before' and 'after' snapshots, and you can >> tell what code was actually executed and therefore tested by your >> tests. > > > Call me dumb, but what I don't understand is why you want to have the > difference between the before and after snapshots, rather than the plain > after snapshot. > Dont ask me, Im just doing what 'man lcov (1)' told me to do here. ;) > > Do you want to filter out any code that is executed "by accident" (as it > belongs to tools we build and already execute at build time, say) rather > than by dedicated tests? > I guess gcov/lcov assume that there is a difference between a.) strictly compiling your project and b.) running tests on your compiled project I guess thats just how the tool was designed to function, and the approach that I took. > > In a sense, even during the tests, very much of our code is executed "by > accident" rather than due to dedicated test code calling it: Especially the > subsequentcheck stuff contains checks that are not simple unit tests, but > start of a complete soffice.bin process, causing "unintended" testing of > large parts of the infrastructure code anyway. > Whether code gets tested 'unintended' or not during your 'tests' is really not relevant, is it ? Only if the code gets executed or not ? Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
On Thu, Aug 23, 2012 at 8:41 PM, Michael Stahl wrote:
> On 23/08/12 18:09, John Smith wrote:
>> Hi,
>>
>>
>> I just finished a first full run of lcov. There was one 'make check'
>> failure though, and there were a lot of 'warnings' running lcov that
>> may need some further investigation. Also, there is some stuff
>> included ('/usr/include/boost', for example) that might not be desired
>> in the report ?
>
> yes, everything under /usr/include is just noise, would be great to
> filter that out.
>
Hrm. Looking at the 'lcov' options now, there seems to be a '--remove
' flag that lets you filter out coverage data for a particular set of
files from a tracefile by specifying a pattern. So I guess that 'lcov
--remove /tmp/libreoffice_total.info /usr/include -o
/tmp//tmp/libreoffice_filtered.info' should do it. I will look into
that one, as soon as 'make build && make check' finally finishes...
Regards,
John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: No output from ./autogen.sh --help and other getting started issues (Ubuntu)
On Fri, Aug 24, 2012 at 11:47 AM, B.J. Herbison wrote: > $ ./autogen.sh --help Im not sure, but arent you supposed to run './autogen.sh' without that help flag, like you did there with '--help' ? So that it creates the configure script for you ? Just my 2$ Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
>> I did have one test fail. See the 'make check failure' thread: >> http://nabble.documentfoundation.org/make-check-failure-td4002979.html >> Could that explain the omission ? > > of course it could, i wasn't connecting those threads :) > Thats good. Well then at least that makes me fairly confident that the results are correct, but others are still invited to take a look though. > > ok then i guess the test wasn't run because of the previous failure; if > that failure happens every time for you, then you can disable the test > locally by commenting out the line sc.ScAccessiblePageHeaderArea in > sc/qa/unoapi/sc.sce and try again. > Thanks, but since the failure of a single test doesnt stop it from executing any further tests, I think ill leave 'sc/qa/unoapi/sc.sce' as it is. But if it does fail every time (I have to check, sorry, make build && make check takes ages on my machine) wouldnt it be a better idea to investigate (if it isnt just me, of course) what is causing the failure ? Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
On Thu, Aug 23, 2012 at 8:41 PM, Michael Stahl wrote:
> On 23/08/12 18:09, John Smith wrote:
>> Hi,
>>
>>
>> I just finished a first full run of lcov. There was one 'make check'
>> failure though, and there were a lot of 'warnings' running lcov that
>> may need some further investigation. Also, there is some stuff
>> included ('/usr/include/boost', for example) that might not be desired
>> in the report ?
>
> yes, everything under /usr/include is just noise, would be great to
> filter that out.
>
Im not sure that can be done. It seems that everything that gets
touched by 'make build' gets instrumented and therefore included in
the report. lcov does have a '--base-directory' and a '--directory'
flag, but those already point to the LibreOffice sources in
'/usr/local/src/libreoffice'.
>
> so looking at a few bits where i'm familiar with the tests tests like:
>
> http://dev-builds.libreoffice.org/lcov_reports/master~2012-08-22_09.11.23/sax/source/tools/converter.cxx.gcov.html
>
> it seems quite plausible.
>
> but looking at
>
> http://dev-builds.libreoffice.org/lcov_reports/master~2012-08-22_09.11.23/unoxml/source/dom/node.cxx.gcov.html
> http://dev-builds.libreoffice.org/lcov_reports/master~2012-08-22_09.11.23/unoxml/source/rdf/librdf_repository.cxx.gcov.html
>
> some functions that are definitely tested like
> librdf_Repository::querySelect or CNode::insertBeforeshow up entirely
> un-executed.
>
I did have one test fail. See the 'make check failure' thread:
http://nabble.documentfoundation.org/make-check-failure-td4002979.html
Could that explain the omission ?
>
> are you running the JUnit based tests as well? i.e. if you use
> --without-java or --without-junit, that would negatively affect the test
> coverage.
>
Im not excluding java or junit. My full configure line is :
LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage' \
CXXFLAGS+='-fprofile-arcs -ftest-coverage' CPPFLAGS+='-fprofile-arcs
-ftest-coverage' \
./configure --disable-odk --with-system-libcmis=no --with-system-hsqldb=no \
--with-system-saxon=no --with-system-libs
>
> these are run during "make subsequentcheck", you should have files like
> workdir/*/JunitTest/unordf_complex/done.log.
>
Yes, I have a few of those.
Regards,
John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'make check' failure
On Fri, Aug 24, 2012 at 10:46 AM, Stephan Bergmann wrote: > > The unoapi tests involving anything related to accessibility have > historically been very fragile (things like expecting a certain GUI element > has focus at a certain moment, which can fail as soon as other apps are > running in parallel), have been cleaned up significantly over time, but > likely still contain problems. Analyzing them is, unfortunately, a black > art. > Thats a shame. Then I guess posting a full log of 'make check' including all output would be pretty pointless ? > >> quickly tried a 'make >> /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/sc_unoapi/user' >> as suggested in the logfile and that just gave me a 'nothing to do for >> foo' response. Can I do a 'make clean' for just that test ? > > > I assume you forgot to "cd sc" before calling make there. > Well I dont know what I did before, but now I get this : make: *** No rule to make target `/usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/sc_unoapi/user'. Stop. :( BTW, I just re-ran 'make check' on slightly newer sources, and got some more failures towards the end (including some core dump, too) Maybe someone should take a look at the output ? http://pastebin.ca/2197812 Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'make check' failure
On Thu, Aug 23, 2012 at 11:45 AM, Michael Stahl wrote: > > reading the log you posted no you don't get a core file because > soffice.bin didn't actually crash. > Ok, so how do we go about getting more detailed info that can assist in solving the issue, then ? (assuming I can reproduce, of course) I quickly tried a 'make /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/sc_unoapi/user' as suggested in the logfile and that just gave me a 'nothing to do for foo' response. Can I do a 'make clean' for just that test ? - John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
Hi,
I just finished a first full run of lcov. There was one 'make check'
failure though, and there were a lot of 'warnings' running lcov that
may need some further investigation. Also, there is some stuff
included ('/usr/include/boost', for example) that might not be desired
in the report ?
I guess the main thing to do first now is to see if this report
actually makes any sense. Essentially, all code that gets executed by
'make check' on toplevel (which does dev-install and subsequentcheck,
and dev-install includes both unitcheck and slowcheck) should show up
as covered in the report. Maybe people that are familiar with the
contents of the checks/tests and what code/functionality they cover
can take a look at that ?
Anyway, the generated html report as it currently is can be found here :
http://dev-builds.libreoffice.org/lcov_reports/
Regards,
John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'make check' failure
On Thu, Aug 23, 2012 at 9:14 AM, Stephan Bergmann wrote: > > you should always run those tests with (bash etc.:) 'ulimit -c unlimited'; > the gbuild logic will automatically print backtraces in case of a crash then > (if your system is set up to generate core files named "core" or > "core." into cwd). > > Stephan > I do have core set to unlimited, but I still got a message that a core could not be generated, and all the output I got was what I posted already. - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
'make check' failure
Hi, I just ran into this error when running 'make check'. Should I file a bug report on that ? Regards, John Smith * Failures that appeared during scenario execution: sc.ScAccessiblePageHeaderArea 1 of 96 tests failed Job run took: 717865ms [00:11:57] Job -sce /usr/local/src/libreoffice/sc/qa/unoapi/sc.sce failed No core dump at /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/sc_unoapi/user, to create core dumps (and stack traces) for crashed soffice instances, enable core dumps with: ulimit -c unlimited E Time: 733.897 There was 1 failure: 1) test(org.openoffice.test.UnoApiTest) java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.openoffice.test.UnoApiTest.test(UnoApiTest.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at org.junit.runner.JUnitCore.run(JUnitCore.java:136) at org.junit.runner.JUnitCore.run(JUnitCore.java:117) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) at org.junit.runner.JUnitCore.main(JUnitCore.java:45) FAILURES!!! Tests run: 1, Failures: 1 to rerun just this failed test without all others, run: make /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/sc_unoapi/user cd into the module dir to run the tests faster Or to do interactive debugging, run two shells with (Linux only): make debugrun make gb_JunitTest_DEBUGRUN=T /usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/sc_unoapi/done make[2]: *** [/usr/local/src/libreoffice/workdir/unxlngi6.pro/JunitTest/sc_unoapi/done] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/usr/local/src/libreoffice' make[1]: *** [subsequentcheck] Error 2 make[1]: Leaving directory `/usr/local/src/libreoffice' make: *** [check] Error 2 # ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
All, Not a new report (yet), but the clang analyzer reports have found a permanent home at this location : http://dev-builds.libreoffice.org/clang_reports/ Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [GSOC-UPDATE](20.08) Impress Remote -- first testing apk.
On Tue, Aug 21, 2012 at 11:50 AM, Michael Meeks wrote: > > So we should help out with that; can you send an ssh key to Thorsten, > and he can get you setup with an account on dev-builds.libreoffice.org - > which is probably the right place to put this stuff. > Thank you very much. I just send an email and ssh pub key to Thorsten. > > It's some great work generating it [ many thanks for that ]. > Well it's actually really easy to do (even a non-dev like me can do it); it just takes hours (literally) of waiting for it to complete. But it's nice to know it's appreciated; I personally got the impression that the devs already have more work to do than they have time for. And certainly not the extra time to examine static analyzer reports to determine if they are actual bugs or just false positives. I guess I was wrong. :) Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
Hi, Im running into an issue I havent seen before on LibreOffice. When I do a make with LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage' CXXFLAGS+='-fprofile-arcs -ftest-coverage' CPPFLAGS+='-fprofile-arcs -ftest-coverage' I now still get an error about "undefined reference to `__gcov_merge_add'" in a specific module 'odk'. Everything up until that point works as expected. I also tried specifying '-lgcov' and '-coverage', but the result is the same. When I 'make odk' I get the output below, but I have no idea what could be causing this ? Any and all help is sincerely appreciated. log for /usr/local/src/libreoffice/odk/source/unoapploader/unx Making:unoapploader /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/findsofficepath.o: In function `_GLOBAL__sub_I_65535_0_findsofficepath.c': findsofficepath.c:(.text+0x429): undefined reference to `__gcov_init' /usr/local/src/libreoffice/solver/unxlngi6.pro/lib/findsofficepath.o:(.data.rel+0x10): undefined reference to `__gcov_merge_add' collect2: error: ld returned 1 exit status dmake: Error code 1, while making '../../../unxlngi6.pro/bin/unoapploader' Regards, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [GSOC-UPDATE](20.08) Impress Remote -- first testing apk.
On Mon, Aug 20, 2012 at 11:11 PM, Michael Meeks wrote: > > I'd be careful of that in case they become popular ;-) I'd suggest you > use your freedesktop webspace; checkout your freedesktop account name > (used to be in .git/config); assuming it is 'ahunt': > > ssh ah...@users.freedesktop.org > > if you make a directory public_html you can drop files in there that > appear at http://users.freedesktop.org/~ahunt/ > Totally off topic, Im sorry, but ... but im intrigued: Could this be a good solution to store the clang static src analysis reports as well ? If so, I guess that would require me to get a account at users.freedesktop.org ? How should I go about getting that ? Again, im sorry for the off-topic question; but it just sounds like a good solution to the 'store html pages where' issue im struggling with. Thanks, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
On Mon, Aug 20, 2012 at 11:43 AM, Bjoern Michaelsen wrote: > On Sun, Aug 19, 2012 at 09:14:52PM +0200, John Smith wrote: >> When I run 'make help' I get this : >> >>unitcheckrun unit tests >>slowcheckrun slow unit tests >>subsequentcheck run system tests (requires full installation) >>checkrun unit tests and if in toplevel subsequentcheck >> >> Which gives me the idea that, when run from the top level, 'make >> check' also runs 'make subsequentcheck ', and that it would make sense >> to also run 'make unitcheck' and 'make slowcheck' here ? Or am I >> missing something ? > > Make check on toplevel does dev-install and subsequentcheck. And dev-install > includes both unitcheck and slowcheck. > > Best, > > Bjoern > Thanks, so 'make check' on the toplevel should be sufficient then to run all the tests. One more question: is there a make target that 'only' builds libreoffice without building any of the tests ? ( I think maybe 'make build' ?) Im not sure if I really will need such a target, but I get the impression that running just 'make' like this "*FLAGS+='-fprofile-arcs -ftest-coverage' make" will result in the actual tests (code) themselves be instrumented for coverage analysis as well as the LibreOffice code; im not quite sure if this matters or not. Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 38840 - Adding coverage analysis to unit tests
On Sun, Aug 19, 2012 at 9:03 PM, Bjoern Michaelsen wrote: > Hi, > > We you run plain make in a module, it the default target already runs the > unitcheck target. If you run make from the top-level, it also runs slowcheck. > Perhaps I got it all wrong, what gets run during the plain 'make' in the toplevel is not really relevant here. The point is to figure out how much code is actually 'tested' with the make check/etc target(s). - First you run a plain make in the top level directory to build LO (with analysis stuff enabled). - then you create a 'baseline' with lcov (sort of create a 'before snapshot' of LO) - *then* you run all your tests (whatever they may be) - then you re-run lcov to create an 'after snapshot' - then you compare the 'before' and 'after' snapshots, and you can tell what code was actually executed and therefore tested by your tests. At least, thats the way I understand it to be. When I run 'make help' I get this : unitcheckrun unit tests slowcheckrun slow unit tests subsequentcheck run system tests (requires full installation) checkrun unit tests and if in toplevel subsequentcheck Which gives me the idea that, when run from the top level, 'make check' also runs 'make subsequentcheck ', and that it would make sense to also run 'make unitcheck' and 'make slowcheck' here ? Or am I missing something ? Thanks for the feedback, Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bug 38840 - Adding coverage analysis to unit tests
Hi, Im playing around with gcov/lcov coverage analysis for a bit, and one of the things im running into/wondering about is what 'tests' should be run ? I believe there are a few 'make targets' that sound like good candidates, but which one to run ? Is 'make check' enough ? Or should I (also/instead) run 'make unitcheck' and 'make slowcheck' ? Or any others ? Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
Hi, Well I finally managed to do a 'scan-build' src analysis of LibreOffice ~master, using clang as the compiler instead of GCC. There still are a few files where analysis failed and clang crashed, but those are only a few (and I submitted a bug report for that at http://llvm.org/bugs/show_bug.cgi?id=13614). The report still includes bits of dbuild, as that still seems to get included in a build. The rest of the ./configure flags were : --disable-ccache As I couldnt get the clang compiler to play nice with ccache cached files. --enable-debug I assumed people would want to include debug code as well. --with-system-libcmis=no The system libcmis is the same version as the inculded one(0.2.3), but... the included one seems to add a few patches that are required for libreoffice, forcing the use of the included version. --with-system-libs As most people didnt want the results to include 3rd party code. --with-system-hsqldb=no --with-system-saxon=no I have been told that the internal version of those are special cases where the internal always are required. The full report is at : http://lbalbalba.x90x.net/clang-analyzer/libreoffice-with-clang/ Have fun, Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Issue using clang compiler and analyzer with libreoffice
On Tue, Aug 14, 2012 at 6:30 PM, John Smith wrote: > > checking if gij knows its java.home... /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5 > checking for jawt lib name... configure: error: jni.h could not be > found. Mismatch between gcc and libgcj or libgcj-devel missing? > Hrm. looks like I have been using a mix of java jre 1.7 and javac jdk 1.5 Simply running : alternatives --config java alternatives --config javac Fixed it for me. Thanks anyway, Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Wed, Aug 8, 2012 at 6:40 PM, Joop Kiefte wrote: > Yes that is possible with github. > Still, it seems like major overkill for something like static html pages to me. You dont really need version control here, right ? People are only gonna be interested in seeing the 'latest' analysis of the newest sources, and not really the analysis of '5-versions-ago' ? Or am i missing something here ? Regards, john Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Wed, Aug 8, 2012 at 2:03 PM, Jesso Murugan wrote: > Hi John, > > If you have problems with space you can put the files as such in github.com, > or I'll > host it somewhere. > > Regards, > Jesso Clarence > Motah Program, KACST > http://www.motah.org.sa Hi Jesso, Thank you for your very kind and generous offer. Another, maybe more permanent location would be great. I doubt github is the best place for them though, because they are essentially a bunch of html files that may be better stored on a web server for easy viewing by everyone. Or is that possible in github ? But im not sure that this exact report is the right one to start with at this point in time (report including all 3rd party code). As others have stated, maybe it would be more realistic to start off with the other report that specifically covers the the libreoffice code only. Ill still leave that report on the site (if there is still enough interest) and update it by running the analyser again (also if there is still enough interest). Thanks, Regards, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
no makefile in 'dmake/tests'
Hi, Im running into a compilation issue on Linux with latest maters sources. There is no 'Makefile' in the dmake/tests directory, only a 'Makefile.am' and a 'Makefile.in'. This stops the build process for me. I was under the impression that that Makefile should be generated by ./configure ? Anway, here's what the output looks like : # make all make -r -f /usr/local/src/libreoffice/Makefile.top all make[1]: Entering directory `/usr/local/src/libreoffice' make[2]: Entering directory `/usr/local/src/libreoffice/dmake' Making distclean in tests make[3]: Entering directory `/usr/local/src/libreoffice/dmake/tests' make[3]: *** No rule to make target `distclean'. Stop. make[3]: Leaving directory `/usr/local/src/libreoffice/dmake/tests' make[2]: *** [distclean-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/libreoffice/dmake' make[1]: *** [/usr/local/src/libreoffice/workdir/unxlngi6.pro/bootstrap] Error 2 make[1]: Leaving directory `/usr/local/src/libreoffice' make: *** [all] Error 2 # ls -l dmake/tests/Make* -rw-r--r--. 1 root root 1133 Aug 4 12:26 dmake/tests/Makefile.am -rw-r--r--. 1 root root 11645 Aug 4 12:26 dmake/tests/Makefile.in Regards, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
If people dont mind, im going to delete (due to limited space reasons) 'http://lbalbalba.x90x.net/clang-analyzer/libreoffice/' which contains the reports with the 3rd party code included (which people didnt seem interested in anyway). Ill leave the other reports alone, which used the system libs, located at 'http://lbalbalba.x90x.net/clang-analyzer/libreoffice-with-system-libs/'. - John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: core dump when compiling LibreOffice ~master
On Tue, Aug 7, 2012 at 4:53 PM, John Smith wrote: > On Tue, Aug 7, 2012 at 3:37 PM, Caolán McNamara wrote: >> >> It's be helpful to find the core.* of the coredump and get a backtrace >> from it. >> > I was under the impression that I already attached a trace with my > first email ? Anyway, here it is again. > Please ignore that email; I forgot I created a bug in bugzilla for it. https://bugs.freedesktop.org/show_bug.cgi?id=53155 Please use that instead. Thanks, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: core dump when compiling LibreOffice ~master
On Tue, Aug 7, 2012 at 3:37 PM, Caolán McNamara wrote: > > It's be helpful to find the core.* of the coredump and get a backtrace > from it. > I was under the impression that I already attached a trace with my first email ? Anyway, here it is again. Regards, John Smith stacktrace.txt.gz Description: GNU Zip compressed data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
> > But it looks like I can do "scan-build --use-cc=clang > --use-c++=clang++ ", im trying that but I still get GCC for > compilation... Will investigate later, gotta go now. > Well now when I do: scan-build --use-cc=/usr/local/bin/clang --use-c++=/usr/local/bin/clang++ \ -o /tmp/foo ./configure --enable-debug --with-system-libcmis=no \ --with-system-saxon=no --with-system-libs I get : checking if gij knows its java.home... /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5 checking for jawt lib name... configure: error: jni.h could not be found. Mismatch between gcc and libgcj or libgcj-devel missing? I dont get that error when I dont use scan-builds '--use-cc/c++' options. - John config.log.gz Description: GNU Zip compressed data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Tue, Aug 7, 2012 at 11:52 AM, Stephan Bergmann wrote: > On 08/07/2012 10:40 AM, John Smith wrote: >> >> It's not clang/clang++ that is executed here: it's the >> ccc-analyzer/c++-analyzer. It sits in front of the compiler you use, >> which is still GCC in this case. After ccc-analyzer/c++-analyzer is >> done with the analysis, it passes all parameters and arguments to the >> actual compiler (GCC), which then proceeds to compile the code as >> usual. Im guessing your fix is trying to detect which compiler is >> used, and thats still (as it is intended) GCC, but doesnt notice the >> analyzer sitting in front of it (again, as intended) . Since none of >> the llvm/clang parts support the __float128 type, the error is still >> produced by ccc-analyzer/c++-analyzer. >> >> If you can try 'scan-build ./configure && scan-build make' on the >> LibreOffice code, you should be able to reproduce it. > > > So you should probably change that to just "scan-build make" (as LO's > default make target automatically calls ./autogen.sh, which in turn calls > ./configure, as necessary), which would hopefully lead to LO's ./configure > seeing a CXX that is the actual scan-build "fake compiler," which would in > turn hopefully lead to the detection that -std=gnu++11 does not work kicking > in (as at least the static analyzer part of the fake compiler would fail on > #include , even if the gcc part succeeded). > > > Stephan > ___ No, configure *does not* detect it. Thats the way it's supposed to work, by design, by the way. It's what 'scan-build ./configure' and 'scan-build make' do: insert a 'fake compiler'. But it looks like I can do "scan-build --use-cc=clang --use-c++=clang++ ", im trying that but I still get GCC for compilation... Will investigate later, gotta go now. Thanks, John Smith. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Tue, Aug 7, 2012 at 10:47 AM, Lubos Lunak wrote: > > It doesn't make much sense to analyze with Clang but compile with GCC. > The idea here is that you can use your existing build setup 'as-is' without being forced to change your build setup like your compiler, Makefiles, etc. And still be able to analyze your codebase, without having to make any other changes. > > Configure detects various features of the compiler and if you actually use > GCC, certain things will not be set up properly for Clang. Use Clang for > compiling too. > Alright, I'll do that the next time I run the analyzer. - John ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Tue, Aug 7, 2012 at 8:57 AM, Stephan Bergmann wrote:
> On 08/06/2012 09:57 AM, John Smith wrote:
>>
>> I submitted a bug report : http://llvm.org/bugs/show_bug.cgi?id=13530
>
>
> Hm, -std=gnu++11 should be disabled for Clang on Fedora 17 (i.e., against
> GCC 4.7 headers) in LO due to
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=85b35ac289f661f64c145deaf419f61f5d4c>
> "Detect failing Clang with GCC 4.7 headers and --std=gnu++0x scenarios."
>
> I had originally designed that changeset when using a home-built "clang
> version 3.1 (tags/RELEASE_31/final 160361)" (where I stumbled over the
> problem in some C++ code that included , so I used that in the
> check). From your bug I see you are using a "clang version 3.2 (trunk
> 161295)," so I now retried with a fresh home-built Clang trunk ("clang
> version 3.2 (trunk 161398)"), and both of my Clang versions consistently
> fail to compile both
>
> #include
>
> and
>
> #include
>
> (in each case choking on "use of undeclared identifier '__float128'").
>
> So I am not sure why your LO build tries to use --std=gnu++0x at all.
>
>
> Stephan
>
It's not clang/clang++ that is executed here: it's the
ccc-analyzer/c++-analyzer. It sits in front of the compiler you use,
which is still GCC in this case. After ccc-analyzer/c++-analyzer is
done with the analysis, it passes all parameters and arguments to the
actual compiler (GCC), which then proceeds to compile the code as
usual. Im guessing your fix is trying to detect which compiler is
used, and thats still (as it is intended) GCC, but doesnt notice the
analyzer sitting in front of it (again, as intended) . Since none of
the llvm/clang parts support the __float128 type, the error is still
produced by ccc-analyzer/c++-analyzer.
If you can try 'scan-build ./configure && scan-build make' on the
LibreOffice code, you should be able to reproduce it.
See this url for some details on how it works:
http://clang-analyzer.llvm.org/scan-build.html
Regards,
John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Mon, Aug 6, 2012 at 9:57 AM, John Smith wrote:
> On Mon, Aug 6, 2012 at 9:08 AM, Stephan Bergmann wrote:
>>
>> That smells like "On recent Fedora 17, the included Clang (3.0) is unusable
>> due to clang++ chokes on . However, a home-built Clang 3.1 works
>> fine."
>> (<https://wiki.documentfoundation.org/Development/Building_LibreOffice_with_Clang#Setup>)
>>
>>
>> Stephan
>>
> Hrm. I did some googling, and I doubt that it's the same bug. This one
> occurs with something like this :
>
> # cat test.cpp
> #include
>
> int main() {
> std::cout << "Hello, world!" << std::endl;
> }
>
> # clang++ test.cpp -o test -std=gnu++11
> In file included from test.cpp:1:
> In file included from
> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/iostream:39:
> In file included from
> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ostream:39:
> In file included from
> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:40:
> In file included from
> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/char_traits.h:40:
> In file included from
> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:65:
> In file included from
> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:61:
> In file included from
> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/move.h:57:
> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/type_traits:256:39:
> error: use of undeclared identifier '__float128'
> struct __is_floating_point_helper<__float128>
> ^
> 1 error generated.
>
>
>
> I submitted a bug report : http://llvm.org/bugs/show_bug.cgi?id=13530
>
>
>
> John Smith.
Well it turns out that Clang (or any backends) doesn't support the
__float128 type (yet). Some possible workarounds are suggested in the
bug report.
- John Smith
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: core dump when compiling LibreOffice ~master
On Mon, Aug 6, 2012 at 10:22 AM, John Smith wrote: > Hi, > > > When I try to compile LibreOffice ~master on Linux, I get a build > failure and a core dump. > > I have attached the build_error.log and the stack trace. > > > My configure and make lines were: > LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage' > CXXFLAGS+='-fprofile-arcs -ftest-coverage' CPPFLAGS+='-fprofile-arcs > -ftest-coverage' ./configure --enable-debug --with-system-libcmis=no > --with-system-saxon=no --with-system-libs > LDFLAGS+='-fprofile-arcs' CFLAGS+='-fprofile-arcs -ftest-coverage' > CXXFLAGS+='-fprofile-arcs -ftest-coverage' CPPFLAGS+='-fprofile-arcs > -ftest-coverage' make > > > Any and all help is appreciated, > > > Regards, > > > John Smith. I decided to file a bug in LibreOffice bugzilla for this one, since it is a component of LibreOffice itself (src/libreoffice/solver/unxlngi6.pro/bin/uno) that is dumping core here. https://bugs.freedesktop.org/show_bug.cgi?id=53155 - John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Mon, Aug 6, 2012 at 8:58 AM, Stephan Bergmann wrote: > > In any case, such stuff should be something we can filter out in some way > (post-processing the data -- is it only available as HTML, or also in some > other format?), so I wouldn't worry about it too much. Just wanted to note > it down... > > > Stephan > > Oh, I almost forgot: Yes, the report is only available as HTML. - John ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Mon, Aug 6, 2012 at 9:08 AM, Stephan Bergmann wrote:
>
> That smells like "On recent Fedora 17, the included Clang (3.0) is unusable
> due to clang++ chokes on . However, a home-built Clang 3.1 works
> fine."
> (<https://wiki.documentfoundation.org/Development/Building_LibreOffice_with_Clang#Setup>)
>
>
> Stephan
>
Hrm. I did some googling, and I doubt that it's the same bug. This one
occurs with something like this :
# cat test.cpp
#include
int main() {
std::cout << "Hello, world!" << std::endl;
}
# clang++ test.cpp -o test -std=gnu++11
In file included from test.cpp:1:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/iostream:39:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ostream:39:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:40:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/char_traits.h:40:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:65:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:61:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/move.h:57:
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/type_traits:256:39:
error: use of undeclared identifier '__float128'
struct __is_floating_point_helper<__float128>
^
1 error generated.
I submitted a bug report : http://llvm.org/bugs/show_bug.cgi?id=13530
John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Mon, Aug 6, 2012 at 8:58 AM, Stephan Bergmann wrote: > On 08/03/2012 03:42 PM, John Smith wrote: >>> >>> - Still lots of "external" stuff, dmake, libxmlsec/unxlngi6.pro, >>> workdir/unxlngi6.pro/LexTarget, ... >>> >> Well, the analyzer simply follows/precedes whatever you tell 'make' to >> do. So if the build includes 'make dbuild', then that *will* not only >> get build, but analyzed as well and show up in the report. I was >> hoping that adding '--with-system-libs' would solve that issue, but >> apparently it doesnt. If there are ./configure switches to disable >> compilation of those final parts - and Fedora pre-build system rpms to >> replace them - then all should be fine. Or perhaps the rest of this >> 'external stuff' should be added to '--with-system-libs', or get it's >> own ./configure switch ? > > > dmake will eventually be obsoleted by our new gbuild machinery and removed. > For the time being, it could help to start analyzing only after dmake has > already been build (it is built in ./bootstrap, so something like > "./autogen.sh && ./bootstrap && make" instead of just "make" might help). > > workdir/unxlngi6.pro/LexTarget contains generated flex output, which itself > is not external code, but the quality of that code, at least partly, is > under the control of the external flex tool. Something of a special case > (hopefully leading to only a few reports anyway, which also might be > worthwhile addressing in upstream flex if they are not false positives). > > In any case, such stuff should be something we can filter out in some way > (post-processing the data -- is it only available as HTML, or also in some > other format?), so I wouldn't worry about it too much. Just wanted to note > it down... > > > Stephan > I'll take a look at building dmake before I start another analysis next time, and see where that gets me. But for the time being, because analysis literally takes *hours* Im just going to wait and see how useful the current report is to people. Has anyone actually fixed a bug yet, based on a analysis report ? (I think I have seen 1 post about a bugfix on this list so far.). - John ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On Mon, Aug 6, 2012 at 9:08 AM, Stephan Bergmann wrote: > On 08/03/2012 06:07 PM, John Smith wrote: >> >> >> /usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/type_traits:256:39: >> error: use of undeclared identifier '__float128' >> struct __is_floating_point_helper<__float128> > > > That smells like "On recent Fedora 17, the included Clang (3.0) is unusable > due to clang++ chokes on . However, a home-built Clang 3.1 works > fine." > (<https://wiki.documentfoundation.org/Development/Building_LibreOffice_with_Clang#Setup>) > > > Stephan > Thanks for pointing that out. I am indeed running Fedora 17. I am not, however, running the included clang, but the (almost) latest svn : # clang --version clang version 3.2 (trunk 161295) Target: i386-pc-linux-gnu Thread model: posix Still weird that that shows up (again ?), though. Regards, John Smith ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
