POV-Ray : Newsgroups : povray.unix : Poll: Any Build Problems? : Re: Poll: Any Build Problems? Server Time
25 May 2024 23:06:45 EDT (-0400)
  Re: Poll: Any Build Problems?  
From: clipka
Date: 13 Nov 2015 16:59:25
Message: <56465d3d$1@news.povray.org>
Am 13.11.2015 um 20:44 schrieb William F Pokorny:

>     libboost-dev
> which is incorrect for debian based systems and should be :
>     libboost-all-dev
> or perhaps the following would work (not tried it) :
>     libboost-thread-dev
> Aside: I think libboost.dev - which exists - is needed for developing
> individual boost libraries and so not what povray needs.

From a quick glance at debian's own package informations on
http://packages.debian.org, I gather that "libboost-dev" is /not/ a
package for boost developers, but rather does adhere to the standard
naming convention that "libwhatever-dev" contains the header files
required to develop software _using_ the "libwhatever" library.

More precisely, the package seems to be a collection of various boost
subprojects (or, more precisely, the header files thereof) that debian
doesn't provide a dedicated library package for.

It should be noted that a lot of the boost subprojects are header-only
libraries, i.e. their code consists entirely of header files, so there
is no corresponding dynamically linked library to distribute. I'd wager
that "libboost-dev" contains exactly the header files making up those

The package "libboost-all-dev", on the other hand, is a collection of
/all/ boost libraries, both those in "libboost-dev" and those with
dedicated library packages.

> The master or 3.7.1-alpha.8344733 branch worked fine, while the
> 3.7-stable branch still required the extra:
>  LIBS="-lboost_system -lboost_thread"

That's good news.

> A surprise for me is that the 3.7.1-alpha.8344733 version of povray
> --benchmark ran about 19% slower than the stable or 3.7.0 version in
> several trials. Expected? There are additional original rays shot in the
> master branch - much less than 19% more - but maybe these extra rays
> "heavy ones" compute wise?

That's not so good news. Maybe the ongoing "C++ification" of the code is
taking more of a toll than I was aware of.

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.