subject:"Re\: Static src analysis of LibreOffice"

On Tue, Aug 7, 2012 at 8:57 AM, Stephan Bergmann sberg...@redhat.com 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 vector, 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 vector

and

#include iostream

(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

2012-08-07 Thread Lubos Lunak

On Tuesday 07 of August 2012, John Smith wrote:
 On Tue, Aug 7, 2012 at 8:57 AM, Stephan Bergmann sberg...@redhat.com 
wrote:
  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.

 It doesn't make much sense to analyze with Clang but compile with GCC. 
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.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
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 l.lu...@suse.cz 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


 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

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: Static src analysis of LibreOffice

2012-08-06 Thread Stephan Bergmann


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
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-08-06 Thread Stephan Bergmann


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 complex. However, a home-built Clang 
3.1 works fine. 
(https://wiki.documentfoundation.org/Development/Building_LibreOffice_with_Clang#Setup)


Stephan
___
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 sberg...@redhat.com 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 complex. 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

Re: Static src analysis of LibreOffice

On Mon, Aug 6, 2012 at 8:58 AM, Stephan Bergmann sberg...@redhat.com 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 sberg...@redhat.com wrote:

 That smells like On recent Fedora 17, the included Clang (3.0) is unusable
 due to clang++ chokes on complex. 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 iostream

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 sberg...@redhat.com 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:57 AM, John Smith lbalba...@gmail.com wrote:
 On Mon, Aug 6, 2012 at 9:08 AM, Stephan Bergmann sberg...@redhat.com wrote:

 That smells like On recent Fedora 17, the included Clang (3.0) is unusable
 due to clang++ chokes on complex. 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 iostream

 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: Static src analysis of LibreOffice

Hi,


Thanks for all the help and tips everyone provided. I finally have
successfully run the clang analyzer on LibreOffice ~master with
'--with-system-libs'. The only exceptions being:

1.) '--with-system-saxon=no'
Because the open source HE variant of saxon does not have all the
necessary features.

2.) '--with-system-libcmis'
Because I couldnt get LO building with Fedora's libcmis-0.2.3 and
libcmis-devel-0.2.3.


I have uploaded the generated report here:
http://lbalbalba.x90x.net/clang-analyzer/libreoffice-with-system-libs/


Please do note that the C++ *analyzer* (not the compiler) is still
very much regarded as a 'work-in-progress' at this point, so you are
likely to run into false positives. And of course, if you do find a
false positive, you can always consider assisting in improving the
analyzer by submitting a test-case and bug report over here ;)  :

http://clang-analyzer.llvm.org/filing_bugs.html




Have fun!



Regards,


John Smith



PS1: Besides possible 'bugs', the compiler also reported quite a few
compiler 'errors'. But because they all looked like the same error, I
have only uploaded the 1st one due to space considerations.

PS2: I would have loved to mention the exact revision of 'master' I
ran this test on, but Im really new to git. Is there a git command
that can provide a human readable/meaningful revision number, like you
can get with 'svn info' ?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-08-03 Thread Michael Meeks

Hi John,

On Fri, 2012-08-03 at 09:00 +0200, John Smith wrote:
 Thanks for all the help and tips everyone provided. I finally have
 successfully run the clang analyzer on LibreOffice ~master with
 '--with-system-libs'. The only exceptions being:

Great :-)

 I have uploaded the generated report here:
 http://lbalbalba.x90x.net/clang-analyzer/libreoffice-with-system-libs/

And we updated the easy-hack bug to point there too IIRC :-)

 PS2: I would have loved to mention the exact revision of 'master' I
 ran this test on, but Im really new to git. Is there a git command
 that can provide a human readable/meaningful revision number, like you
 can get with 'svn info' ?

There are lots of ways, this works:

git log | head -n1

And requires little mental space to remember ;-)

I guess we'd want to do that build regularly; perhaps doing some
tweaking to make it part of Lubos' clang / tinderbox build might be a
good long-term solution ?

Thanks !

Michael.

-- 
michael.me...@suse.com  , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

Glad you like it. Yes, a permanent regular solution is a good idea,
but i have no idea onhow to intergrate it in your current solution.


On 8/3/12, Michael Meeks michael.me...@suse.com wrote:
 Hi John,

 On Fri, 2012-08-03 at 09:00 +0200, John Smith wrote:
 Thanks for all the help and tips everyone provided. I finally have
 successfully run the clang analyzer on LibreOffice ~master with
 '--with-system-libs'. The only exceptions being:

   Great :-)

 I have uploaded the generated report here:
 http://lbalbalba.x90x.net/clang-analyzer/libreoffice-with-system-libs/

   And we updated the easy-hack bug to point there too IIRC :-)

 PS2: I would have loved to mention the exact revision of 'master' I
 ran this test on, but Im really new to git. Is there a git command
 that can provide a human readable/meaningful revision number, like you
 can get with 'svn info' ?

   There are lots of ways, this works:

   git log | head -n1

   And requires little mental space to remember ;-)

   I guess we'd want to do that build regularly; perhaps doing some
 tweaking to make it part of Lubos' clang / tinderbox build might be a
 good long-term solution ?

   Thanks !

   Michael.

 --
 michael.me...@suse.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-08-03 Thread Olivier Hallot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi
Like unusedcode.easy, your file could be placed in the git tree root and
updated periodically.

Just a suggestion.

regards

Em 03-08-2012 08:19, John Smith escreveu:
 Glad you like it. Yes, a permanent regular solution is a good idea,
 but i have no idea onhow to intergrate it in your current solution.
 
 
 On 8/3/12, Michael Meeks michael.me...@suse.com wrote:
 Hi John,

 On Fri, 2012-08-03 at 09:00 +0200, John Smith wrote:
 Thanks for all the help and tips everyone provided. I finally have
 successfully run the clang analyzer on LibreOffice ~master with
 '--with-system-libs'. The only exceptions being:

  Great :-)

 I have uploaded the generated report here:
 http://lbalbalba.x90x.net/clang-analyzer/libreoffice-with-system-libs/

  And we updated the easy-hack bug to point there too IIRC :-)

 PS2: I would have loved to mention the exact revision of 'master' I
 ran this test on, but Im really new to git. Is there a git command
 that can provide a human readable/meaningful revision number, like you
 can get with 'svn info' ?

  There are lots of ways, this works:

  git log | head -n1

  And requires little mental space to remember ;-)

  I guess we'd want to do that build regularly; perhaps doing some
 tweaking to make it part of Lubos' clang / tinderbox build might be a
 good long-term solution ?

  Thanks !

  Michael.

 --
 michael.me...@suse.com  , Pseudo Engineer, itinerant idiot


 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
 

- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
The Document Foundation, Zimmerstr. 69, 10117 Berlin, Germany
Fundação responsável civilmente, de acordo com o direito civil
Detalhes Legais: http://www.documentfoundation.org/imprint
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQG7XZAAoJEJp3R7nH3vLxafwIAI6lNLydCvMNonk6hG9aEid0
QweRGHwyZVIW0ZWY8UEClgqxzb+5j7ghbgkCF0xEBaYg+pK/H30DOKK22zUDTGoG
uoKHstMa0wo3lUd6SmYAnqMf6FfzxIB9uollxkr7UIH8vokpOuZ+DoKm6MpLcOWS
rGQH/ffXeDdivarQyALVzBh3ntIKw1J1L2SvNHL22omqWFYYH7hudRkwUtXhRSkA
tPUUguBIX4w4BRbzNeG6LdAo5Avqj3bTUBnlHp51VJ03wiueUWsIhv0CZLOY095k
FWkTCE4mwcSYXueLk9lNQMkg65SUJupTirKBOZdagGpcxLPt6TlfkqbNMuvqplU=
=QKMP
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Fri, Aug 3, 2012 at 1:00 PM, Michael Meeks michael.me...@suse.com wrote:

 I guess we'd want to do that build regularly; perhaps doing some
 tweaking to make it part of Lubos' clang / tinderbox build might be a
 good long-term solution ?

Hrm. On second thought, maybe we should wait to see if the reports are
actually investigated first, before we start working on a more
permanent and regularly updated system ? Permanent updated exports
arent really useful if nobody takes the time to investigate.


On Fri, Aug 3, 2012 at 1:28 PM, Olivier Hallot
olivier.hal...@documentfoundation.org wrote:

 Like unusedcode.easy, your file could be placed in the git tree root and
 updated periodically.

Well it's not a single file: it's 2 directories filled with annotated
source files. Also, all of it's HTML, so a web server would seem like
a more fitting solution for storing the reports.




Just my 2$



Regards,


John Smith
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Fri, Aug 3, 2012 at 1:00 PM, Michael Meeks michael.me...@suse.com wrote:

 PS2: I would have loved to mention the exact revision of 'master' I
 ran this test on, but Im really new to git. Is there a git command
 that can provide a human readable/meaningful revision number, like you
 can get with 'svn info' ?

 There are lots of ways, this works:

 git log | head -n1

 And requires little mental space to remember ;-)

Ah. So the 'git revision number' is the has of the last commit ?. Ok,
in that case the report was run on
'79e1b9cb2305bc00665e94afd6a00e9f18b76bf8'


Regards,


John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-08-03 Thread Lubos Lunak

On Friday 03 of August 2012, Michael Meeks wrote:
 On Fri, 2012-08-03 at 09:00 +0200, John Smith wrote:
  Thanks for all the help and tips everyone provided. I finally have
  successfully run the clang analyzer on LibreOffice ~master with
  '--with-system-libs'. The only exceptions being:
...
   I guess we'd want to do that build regularly; perhaps doing some
 tweaking to make it part of Lubos' clang / tinderbox build might be a
 good long-term solution ?

 I think the analyzer runs much longer than plain compilation, and as long as 
#18 is the only tinderbox for that platform, I'd like it to run fast. If 
needed, a separate tinderbox elsewhere should do. Especially given that the 
static analysis doesn't really need to be run several times a day.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Fri, Aug 3, 2012 at 3:10 PM, Stephan Bergmann sberg...@redhat.com 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 ?


Regards,


John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Fri, Aug 3, 2012 at 3:20 PM, Lubos Lunak l.lu...@suse.cz wrote:

  I think the analyzer runs much longer than plain compilation, and as long as
 #18 is the only tinderbox for that platform, I'd like it to run fast. If
 needed, a separate tinderbox elsewhere should do. Especially given that the
 static analysis doesn't really need to be run several times a day.

Yes, the analyzer easily runs 6 times as long as a 'normal' build;
about 12 hours on the past libreoffice master run if I remember
correctly. And I agree that a static analyzer probably doesnt need to
be run several times a day; I was thinking that once a week at most
should be good enough already ?

Just my 2$


John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-08-03 Thread Noel Grandin



On 2012-08-03 15:42, John Smith wrote:

Well, the analyzer simply follows/precedes whatever you tell 'make' to
do. So if the build includes 'make dbuild', then that *will* not only

Is there not some kind of path based post-filter for the analyser?
So we can tell it to filter out errors belong to certain path hierarchies?


Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Fri, Aug 3, 2012 at 3:10 PM, Stephan Bergmann sberg...@redhat.com wrote:

 - Truckloads of Other Error: The analyzer had problems processing the
 following files

Yes, but all of them actually look exactly like this one here below.
(and I only uploaded the 1st one of them in the report). 'Other
errors' usually mean 'compiler errors', where the word 'error' is
defined exactly as in GCC: a coding error was encountered that would
have made it impossible to compile the code (and not 'just a logic
bug'). GCC sometimes does seems to be more forgiving in that respect
than clang.


In file included from
/usr/local/src/libreoffice/lotuswordpro/source/filter/xfilter/xfcolor.cxx:61:
In file included from
/usr/local/src/libreoffice/lotuswordpro/source/filter/xfilter/xfcolor.hxx:63:
In file included from
/usr/local/src/libreoffice/lotuswordpro/source/filter/xfilter/xfglobal.hxx:71:
In file included from
/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/rtl/ustring.hxx:38:
In file included from
/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/rtl/string.hxx:42:
In file included from
/usr/local/src/libreoffice/solver/unxlngi6.pro/inc/sal/log.hxx:36:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/sstream:38:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.7.0/../../../../include/c++/4.7.0/istream: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.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Fri, Aug 3, 2012 at 3:56 PM, Noel Grandin n...@peralex.com wrote:

 On 2012-08-03 15:42, John Smith wrote:

 Well, the analyzer simply follows/precedes whatever you tell 'make' to
 do. So if the build includes 'make dbuild', then that *will* not only

 Is there not some kind of path based post-filter for the analyser?
 So we can tell it to filter out errors belong to certain path hierarchies?

Im afraid not. But if we can tell 'make' to skip building those, that
would do it.


Regards,


John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-08-03 Thread Enrico Weigelt


 most likely the versions on the system are too old for LO.  e.g. we
 depend on the mdds 0.6 that was just released a week ago.

I could provide packages for Ubuntu and Debian, if someone likes.
Just drop me a note (personally, not through the list).

 and hsqldb and saxon are special cases where we almost always have to
 use the internal ones; maybe --with-system-libs should not affect
 those...

in which way are they special ?


cu
-- 
Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

enrico.weig...@vnc.biz; www.vnc.de 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Fri, Aug 3, 2012 at 6:55 PM, Enrico Weigelt enrico.weig...@vnc.biz wrote:

 and hsqldb and saxon are special cases where we almost always have to
 use the internal ones; maybe --with-system-libs should not affect
 those...

 in which way are they special ?

saxon comes in a few different versions: free open-source (with
limited features), and payed versions (with more features enabled).
The open source HE (home edition) variant of saxon does not have all
the necessary features: 'http://www.saxonica.com/feature-matrix.html'

I wouldnt know what makes hsqldb special though.


Regards,


John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-31 Thread David Tardon

Hi,

On Mon, Jul 30, 2012 at 01:42:44PM +0200, John Smith wrote:
 On Mon, Jul 30, 2012 at 12:29 PM, Tor Lillqvist t...@iki.fi wrote:
  So if there
  is a way to configure LO (configure --without-foo --without-bar, or
  something) to not make it compile all the 3rd party stuff,
 
  --with-system-libs. How well that works (how many of the 3rd-party
  libs you still need to compile) depends on your distro and version.
 
 Well im on my way to install all the needed libraries when configuring
 --with-system-libs
 
 But now ikm running into something I simply dont understand
 
 lo ./configure gives me :
 
 checking for __db185_open in -ldb4... configure: error: db library not
 found. Use the correct -L flag,
 no
 or install the Berkeley db development package.
 
 
 but rpm -qa gives me :
 
 db4-cxx-4.8.30-10.fc17.i686
 db4-devel-4.8.30-10.fc17.i686
 db4-4.8.30-10.fc17.i686
 
 
 I have no idea whats going on, or how to fix it...
 [ running Fedora 17 ]

You want libdb-devel .

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-31 Thread David Tardon

Hi,

On Mon, Jul 30, 2012 at 03:08:04PM +0200, John Smith wrote:
 On Mon, Jul 30, 2012 at 2:58 PM, Michael Stahl mst...@redhat.com wrote:
  On 30/07/12 14:50, John Smith wrote:
 
  If someone knows how to fix that: let me know
  If it's not really a big deal: Ill do a analysis of libreoffice this way 
  now.
 
  most likely the versions on the system are too old for LO.  e.g. we
  depend on the mdds 0.6 that was just released a week ago.
 
 Hrm. Im having 0.5-something, so youre probably right

There is mdds-devel-0.6.0-2.fc17.noarch available in updates-testing. Run

yum update --enablerepo=updates-testing mdds-devel

to get it.

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-31 Thread John Smith

Well, after a lot of tweaking, I almost have 'configure' working with
'--with-system-libs' now, except for saxon.

Running configure with my system saxon gives me : configure: error:
saxontest could not be compiled, non-functional saxon jar
Even though I have saxon installed. I cant figure out whats going
wrong here. Ive attached my config.log for details, if anyone wants to
look at it.

Thanks,


Regards,


John Smith.


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

2012-07-31 Thread David Tardon

Hi,

On Tue, Jul 31, 2012 at 08:03:00AM +0200, John Smith wrote:
 Well, after a lot of tweaking, I almost have 'configure' working with
 '--with-system-libs' now, except for saxon.
 
 Running configure with my system saxon gives me : configure: error:
 saxontest could not be compiled, non-functional saxon jar
 Even though I have saxon installed. I cant figure out whats going
 wrong here. Ive attached my config.log for details, if anyone wants to
 look at it.

You cannot use system saxon, because the open source HE variant does not
support all the features we need
(http://www.saxonica.com/feature-matrix.html). I guess that does not
matter for static analysis, but then saxon is java, not C++, so it does
not get in the way :-)

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-30 Thread Michael Meeks

Hi John,

On Sun, 2012-07-29 at 21:33 +0200, John Smith wrote:
 But it looks like there still is a need for a place to store the html
 output reports somewhere ? I have (limited) space on

Wow :-) it's nice to have that publicly available.

 http://lbalbalba.x90x.net/clang-analyzer/libreoffice/

Looks really interesting.

 but it sounds like a more structured and permanent way of storing the
 reports is needed ? Or should I just go ahead and put that URL in the
 bug report for the time being? (dont know how long I will be able to
 store it there).

So - if you send a few patches to fix some of the issues - I'll get you
a freedesktop commit account which comes with shell access  some web
space - how does that sound ? :-) [ modulo anyone wanting to add this to
the clang tinderbox etc. ;-]

ATB,

Michael.

-- 
michael.me...@suse.com  , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Mon, Jul 30, 2012 at 10:26 AM, Michael Meeks michael.me...@suse.com wrote:

 So - if you send a few patches to fix some of the issues - I'll get 
 you
 a freedesktop commit account which comes with shell access  some web
 space - how does that sound ? :-) [ modulo anyone wanting to add this to
 the clang tinderbox etc. ;-]


Sounds great, except for the 'send a few patches' part. Im not a
developer myself. But writing a unix shell script that automates 'git
pull, scan-build make, ftp upload' is doable for me. That way you can
schedule the job to run anytime you want to, without having to rely on
me doing it when I have the spare time available. Is the space you are
talking about large enough to store the LibreOffice sources and the
resulting report ? Or do I need separate places for 1) doing the
analysis on the src and 2) uploading the reports ?

But if all that is too ambitious, I can just run the analyzer on my
local machine from time to time, and upload it to the web space you
mentioned.


Regards,


John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-30 Thread Olivier Hallot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

HI

Great tool indeed. Thanks for the work

On a second look, most of the issues are with 3rd parties code (nss,
openldap, berkeleydb, etc...)

ATB

Olivier

Em 29-07-2012 15:20, John Smith escreveu:
 Hi,
 
 
 I have been playing around with the llvm/clang static source code
 analyzer (http://clang.llvm.org/get_started.html) for a while now, and
 thought it might be fun and beneficial to run the analyzer on the
 libreoffice ('master') source code. For those interested the results
 can be found here :
 
 http://lbalbalba.x90x.net/clang-analyzer/libreoffice/
 
 I briefly considered filing a bug report, but I thought it might be a
 much better idea to see what kind of response (if any) I get on this
 list first.
 
 
 All thoughts and comments are more than welcome; let me know what you think.
 
 
 
 Regards,
 
 
 
 John Smith.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
 

- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
The Document Foundation, Zimmerstr. 69, 10117 Berlin, Germany
Fundação responsável civilmente, de acordo com o direito civil
Detalhes Legais: http://www.documentfoundation.org/imprint
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQFleuAAoJEJp3R7nH3vLxHvwH/1FtjlD3ctEQy7RMlXikgu2z
GK+NEvynGMgHh1iRT/xS5FfSRCeUWPhhXb0+sk6Ii9cDUPDl4vZfhnh4yJaSjH9q
Jnu6ag4zJGV14E9X/+BF6oysXzI+Glm1qA41u0azTw/EGQGlZlIdLTQGO9xTV9Zj
son7yXfPg3I+n8o4DQy9cKDznTH4gEfZdsNEITpfiTtbHCyOnQ0b8Kx5cH0LCWjN
7t7E1iMA09LzJMn9jmRN0M/BWh5xNzuk0y04m1kyxb07pZqZ9R69fK5wOK0zlTia
uGm7qLwhsLzZRa1ZfsVeKtswmllzQGSc+rjSBWxl3RvwrRQ8Dbdgu/zcPpVDu5M=
=FxUg
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Mon, Jul 30, 2012 at 11:45 AM, Olivier Hallot
olivier.hal...@documentfoundation.org wrote:

 On a second look, most of the issues are with 3rd parties code (nss,
 openldap, berkeleydb, etc...)

Maybe. But even so, bugs in 3rd party software that LibreOffice
depends on, potentially means problems in LibreOffice, right ?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-30 Thread Olivier Hallot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

Em 30-07-2012 06:50, John Smith escreveu:
 On Mon, Jul 30, 2012 at 11:45 AM, Olivier Hallot
 olivier.hal...@documentfoundation.org wrote:

 On a second look, most of the issues are with 3rd parties code (nss,
 openldap, berkeleydb, etc...)

 Maybe. But even so, bugs in 3rd party software that LibreOffice
 depends on, potentially means problems in LibreOffice, right ?
 

Absolutely right... I just feel a bit less guilty...  :-)
- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
The Document Foundation, Zimmerstr. 69, 10117 Berlin, Germany
Fundação responsável civilmente, de acordo com o direito civil
Detalhes Legais: http://www.documentfoundation.org/imprint
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQFln8AAoJEJp3R7nH3vLxs6MH/2PcNUygut0FOeReH4H6+CIa
F5ZxqpY5z7OUkJwUWgklwVs/VLOA65i7JMOgNwEN7KNHu0ymmL6mr52DBX05c6mb
CtRRfQreYLcHjQlfamSIJxDgPSsSaJVTOuLH+hWxzz1uMfasTUKVzwoz4eIXBfZB
gxtGrO6+vjIfwS2vrS7UMIdL/cjfe4uio67P1GJ6c3W/BQOFaIT3kXTMX+3R8M8A
rP723ZwJtJa2d1SZPCY1BXOMzmJfYePVGT+zN63IxfIKC8VUAyQmxiDji0GQPf3t
uYW2SSud3LknvpKo/Ty70HlrHsSJXXeAJWZr89eNjLyltrREevOw8QAceSABof4=
=Ubns
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-30 Thread Noel Grandin



On 2012-07-30 11:50, John Smith wrote:

On Mon, Jul 30, 2012 at 11:45 AM, Olivier Hallot
olivier.hal...@documentfoundation.org wrote:

On a second look, most of the issues are with 3rd parties code (nss,
openldap, berkeleydb, etc...)


Maybe. But even so, bugs in 3rd party software that LibreOffice
depends on, potentially means problems in LibreOffice, right ?



Yeah, but it's a lot more painful working on that stuff because of the 
need to push it upstream.
I personally, would prefer a report that focussed on the LO-specific 
code, at least until we get the report down to a manageable size.


Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Mon, Jul 30, 2012 at 12:02 PM, Noel Grandin n...@peralex.com wrote:

 On 2012-07-30 11:50, John Smith wrote:

 Maybe. But even so, bugs in 3rd party software that LibreOffice
 depends on, potentially means problems in LibreOffice, right ?


 Yeah, but it's a lot more painful working on that stuff because of the need
 to push it upstream.
 I personally, would prefer a report that focussed on the LO-specific code,
 at least until we get the report down to a manageable size.

Well the analyzer simply 'follows' what you are compiling. So if there
is a way to configure LO (configure --without-foo --without-bar, or
something) to not make it compile all the 3rd party stuff, you
theoretically could generate a report on 'LO only', I guess.


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, Jul 30, 2012 at 12:07 PM, John Smith lbalba...@gmail.com wrote:
 On Mon, Jul 30, 2012 at 12:02 PM, Noel Grandin n...@peralex.com wrote:

 On 2012-07-30 11:50, John Smith wrote:

 Maybe. But even so, bugs in 3rd party software that LibreOffice
 depends on, potentially means problems in LibreOffice, right ?


 Yeah, but it's a lot more painful working on that stuff because of the need
 to push it upstream.
 I personally, would prefer a report that focussed on the LO-specific code,
 at least until we get the report down to a manageable size.

 Well the analyzer simply 'follows' what you are compiling. So if there
 is a way to configure LO (configure --without-foo --without-bar, or
 something) to not make it compile all the 3rd party stuff, you
 theoretically could generate a report on 'LO only', I guess.

PS: Would './configure --disable-extensions' be 'close enough' for
this purpose ?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-30 Thread Tor Lillqvist

 So if there
 is a way to configure LO (configure --without-foo --without-bar, or
 something) to not make it compile all the 3rd party stuff,

--with-system-libs. How well that works (how many of the 3rd-party
libs you still need to compile) depends on your distro and version.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Mon, Jul 30, 2012 at 12:29 PM, Tor Lillqvist t...@iki.fi wrote:
 So if there
 is a way to configure LO (configure --without-foo --without-bar, or
 something) to not make it compile all the 3rd party stuff,

 --with-system-libs. How well that works (how many of the 3rd-party
 libs you still need to compile) depends on your distro and version.

Well im on my way to install all the needed libraries when configuring
--with-system-libs

But now ikm running into something I simply dont understand

lo ./configure gives me :

checking for __db185_open in -ldb4... configure: error: db library not
found. Use the correct -L flag,
no
or install the Berkeley db development package.


but rpm -qa gives me :

db4-cxx-4.8.30-10.fc17.i686
db4-devel-4.8.30-10.fc17.i686
db4-4.8.30-10.fc17.i686


I have no idea whats going on, or how to fix it...
[ running Fedora 17 ]
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-30 Thread Miklos Vajna

On Mon, Jul 30, 2012 at 01:42:44PM +0200, John Smith lbalba...@gmail.com 
wrote:
 but rpm -qa gives me :
 
 db4-cxx-4.8.30-10.fc17.i686
 db4-devel-4.8.30-10.fc17.i686
 db4-4.8.30-10.fc17.i686
 
 I have no idea whats going on, or how to fix it...
 [ running Fedora 17 ]

Reading http://www.libreoffice.org/developers-2/:

Did you run sudo yum-builddep libreoffice already?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Mon, Jul 30, 2012 at 2:29 PM, Miklos Vajna vmik...@suse.cz wrote:

 Did you run sudo yum-builddep libreoffice already?

Thanks! that helped a lot. But I still have to do
 ./configure --with-system-hsqldb=no --with-system-saxon=no
--with-system-mdds=no --with-system-libs 
for configure to be satisfied, even though I have installed the
required packages and packages-devel on my system.

If someone knows how to fix that: let me know
If it's not really a big deal: Ill do a analysis of libreoffice this way now.


Regards,


John Smith
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

2012-07-30 Thread Michael Stahl

On 30/07/12 14:50, John Smith wrote:
 On Mon, Jul 30, 2012 at 2:29 PM, Miklos Vajna vmik...@suse.cz wrote:

 Did you run sudo yum-builddep libreoffice already?

 Thanks! that helped a lot. But I still have to do
  ./configure --with-system-hsqldb=no --with-system-saxon=no
 --with-system-mdds=no --with-system-libs 
 for configure to be satisfied, even though I have installed the
 required packages and packages-devel on my system.
 
 If someone knows how to fix that: let me know
 If it's not really a big deal: Ill do a analysis of libreoffice this way now.

most likely the versions on the system are too old for LO.  e.g. we
depend on the mdds 0.6 that was just released a week ago.

and hsqldb and saxon are special cases where we almost always have to
use the internal ones; maybe --with-system-libs should not affect those...

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

On Mon, Jul 30, 2012 at 2:58 PM, Michael Stahl mst...@redhat.com wrote:
 On 30/07/12 14:50, John Smith wrote:

 If someone knows how to fix that: let me know
 If it's not really a big deal: Ill do a analysis of libreoffice this way now.

 most likely the versions on the system are too old for LO.  e.g. we
 depend on the mdds 0.6 that was just released a week ago.

Hrm. Im having 0.5-something, so youre probably right


 and hsqldb and saxon are special cases where we almost always have to
 use the internal ones; maybe --with-system-libs should not affect those...

Ok.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice

Ok, so I now scan/build using :

scan-build ./configure --with-system-hsqldb=no --with-system-saxon=no
--with-system-libs
scan-build make

But I get no reports wjhatsoever, just this :

-

Entering /usr/local/src/libreoffice/cli_ure/version

/bin/cp version.txt ../unxlngi6.pro/bin/cliureversion.mk
cli_ure deliver
Module 'cli_ure' delivered successfully. 1 files copied, 4 files unchanged

---
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/hsqldb

 it seems that the error is inside 'hsqldb', please re-run build
 inside this module to isolate the error and/or test your fix:

build_error.log should contain the captured output of the failed module(s)

-

PS: I get the same error when not using clang/llvm's scan-build, and
'just' do a regular 'make'



Regards,


John Smith
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Static src analysis of LibreOffice