 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
We've been having problems with the Unix build process in the past, often
related to the boost libraries. I'm wondering where we're at with these issues
right now with the current master branch.
If the 3.7 build process has ever failed to work "out of the box" for you (i.e.
strictly following the baseline build instructions described in `unix/README`),
I'd love to hear from you:
- What variant of Unix are you using?
- What version of the boost library are you using?
- Does the official stable 3.7.0.0 build "out of the box" on your system?
Otherwise, what problems do you encounter, and how (if at all) do you manage to
get it to build?
- Does the current master 3.7.1-alpha.8344773 build "out of the box" on your
system? Otherwise, what problems do you encounter, and how (if at all) do you
manage to get it to build?
- Any other observations?
(Please do NOT reply if the 3.7 build process has always worked perfectly fine
for you.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> We've been having problems with the Unix build process in the past, often
> related to the boost libraries. I'm wondering where we're at with these issues
> right now with the current master branch.
>
> If the 3.7 build process has ever failed to work "out of the box" for you (i.e.
> strictly following the baseline build instructions described in `unix/README`),
> I'd love to hear from you:
>
> - What variant of Unix are you using?
> - What version of the boost library are you using?
>
> - Does the official stable 3.7.0.0 build "out of the box" on your system?
> Otherwise, what problems do you encounter, and how (if at all) do you manage to
> get it to build?
>
> - Does the current master 3.7.1-alpha.8344773 build "out of the box" on your
> system? Otherwise, what problems do you encounter, and how (if at all) do you
> manage to get it to build?
>
> - Any other observations?
>
>
> (Please do NOT reply if the 3.7 build process has always worked perfectly fine
> for you.)
1- Using Raspbian from latest NOOBS for Raspberry Pi 2
2- Lib Version 1.55
3- official 3.7.0.0 stops on ./prebuild process. Master Branch solves that
4- current master does not compile. Can't find boost.thread lib version
5- I don't know much about this stuff but looks like boost distribution on the
RPi NOOBS package has certair incompatibilities with c++ compiler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/13/2015 05:55 AM, clipka wrote:
> We've been having problems with the Unix build process in the past, often
> related to the boost libraries. I'm wondering where we're at with these issues
> right now with the current master branch.
>
> If the 3.7 build process has ever failed to work "out of the box" for you (i.e.
> strictly following the baseline build instructions described in `unix/README`),
> I'd love to hear from you:
>
> - What variant of Unix are you using?
> - What version of the boost library are you using?
>
> - Does the official stable 3.7.0.0 build "out of the box" on your system?
> Otherwise, what problems do you encounter, and how (if at all) do you manage to
> get it to build?
>
> - Does the current master 3.7.1-alpha.8344773 build "out of the box" on your
> system? Otherwise, what problems do you encounter, and how (if at all) do you
> manage to get it to build?
>
> - Any other observations?
>
>
> (Please do NOT reply if the 3.7 build process has always worked perfectly fine
> for you.)
>
>
Christoph,
Let me start by saying when we pull the source code (master) with:
git clone https://github.com/POV-Ray/povray.git
what we get for README* files in the unix directory is a bit confusing.
Namely:
README -> I believe this is an old linux build from source instruction file.
README.MD -> This is the valid one I think and "probably" some developer
script is/was supposed to replace the README above with it before ship.
This README.MD is OK except at the bottom where the dependencies are
listed. For the "boost" libraries it has :
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.
README.unix -> Old 3.6 linux install information along with a some
information that might still be useful.
README.bin -> For the days when some linux binaries were provided I guess.
------------------------------- On Ubuntu 14.04.01
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"
on the ./configure command. The ./prebuild is also noisier warning wise
with the stable version, but worked for me.
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?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
subprojects.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.11.2015 um 11:55 schrieb clipka:
> - What variant of Unix are you using?
> - What version of the boost library are you using?
>
> - Does the official stable 3.7.0.0 build "out of the box" on your system?
> Otherwise, what problems do you encounter, and how (if at all) do you manage to
> get it to build?
>
> - Does the current master 3.7.1-alpha.8344773 build "out of the box" on your
> system? Otherwise, what problems do you encounter, and how (if at all) do you
> manage to get it to build?
>
> - Any other observations?
I just noticed that it might also be of interest to know what compiler
you are using.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 13.11.2015 um 11:55 schrieb clipka:
>
> > - What variant of Unix are you using?
> > - What version of the boost library are you using?
> >
> > - Does the official stable 3.7.0.0 build "out of the box" on your system?
> > Otherwise, what problems do you encounter, and how (if at all) do you manage to
> > get it to build?
> >
> > - Does the current master 3.7.1-alpha.8344773 build "out of the box" on your
> > system? Otherwise, what problems do you encounter, and how (if at all) do you
> > manage to get it to build?
> >
> > - Any other observations?
>
> I just noticed that it might also be of interest to know what compiler
> you are using.
I'm using g++ compiler on RPi 2 NOOBS Raspian, apparently the boost distribution
in the
NOOBS package has conflicts with g++ compiler. I was adviced to try remove all
Boost library using $ aptitude and download and compile the library myself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/13/2015 04:59 PM, clipka wrote:
...
>
Thanks for the additional information on what libboost-dev really is.
I was thinking some more and two packages not in the unix/README.md
"Dependencies" list that I'd vote to be there are autoconf and
libsdl-dev. We need the autoconf package for the configuration process.
The Simple DirectMedia Layer libsdl-dev package is required for the
povray render display (+D) to work. The need for latter package is
mentioned in the unix/install.txt file, but I expect the display
capability is something most users will want.
So, to be complete for my fresh Unbuntu 14.04 install I ended up running
this set of commands in an xterm window:
sudo apt-get update
sudo apt-get -y install autoconf
sudo apt-get -y install build-essential
sudo apt-get -y install git
sudo apt-get -y install libboost-all-dev
sudo apt-get -y install libjpeg-dev
sudo apt-get -y install libopenexr-dev
sudo apt-get -y install libpng-dev
sudo apt-get -y install libsdl-dev
sudo apt-get -y install libtiff-dev
sudo apt-get -y install unzip
sudo apt-get -y install zlib1g-dev
The generic names resolve to versions of the libraries which are fine
for the povray 3.7* compile. The build-essentail and unzip are likely
redundant/not strictly needed. Further, git is needed for the build only
if pulling/managing the source code with git.
Lastly, you'd asked about versions of boost and gcc. Unbuntu 14.04
libboost-all-dev resolves to boost version 1.54. The gcc compiler
version is 4.8.4.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> We've been having problems with the Unix build process in the past, often
> related to the boost libraries. I'm wondering where we're at with these issues
> right now with the current master branch.
>
> If the 3.7 build process has ever failed to work "out of the box" for you (i.e.
> strictly following the baseline build instructions described in `unix/README`),
> I'd love to hear from you:
>
> - What variant of Unix are you using?
> - What version of the boost library are you using?
>
> - Does the official stable 3.7.0.0 build "out of the box" on your system?
> Otherwise, what problems do you encounter, and how (if at all) do you manage to
> get it to build?
>
> - Does the current master 3.7.1-alpha.8344773 build "out of the box" on your
> system? Otherwise, what problems do you encounter, and how (if at all) do you
> manage to get it to build?
>
> - Any other observations?
>
>
> (Please do NOT reply if the 3.7 build process has always worked perfectly fine
> for you.)
Fails at the ./prebuild.sh in the unix/ directory. This is both on FreeBSD 10.2
and Debian testing with the official stable 3.7.0.0 build. On both systems I
get:
configure.ac:302: the top level
+ cat ./configure
+ sed -e 's,configure.gnu --help=recursive,& --srcdir=$ac_srcdir,g' -e 's,\(cd
\)\($ac_\)\(pop\)*\(dir\),\1"\2\3\4",g' -e
's,$am_aux_dir/missing,\\"$am_aux_dir\\"/missing,g'
+ mv -f ./configure.tmp ./configure
+ chmod +x ./configure
+ rm -f -r ./autom4te.cache
sed: ./Makefile.in: No such file or directory
So, it's not generating Makefile.in for some reason.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.03.2016 um 07:22 schrieb jhu:
> "clipka" <nomail@nomail> wrote:
>> We've been having problems with the Unix build process in the past, often
>> related to the boost libraries. I'm wondering where we're at with these issues
>> right now with the current master branch.
...
>> - Does the official stable 3.7.0.0 build "out of the box" on your system?
>> Otherwise, what problems do you encounter, and how (if at all) do you manage to
>> get it to build?
>>
>> - Does the current master 3.7.1-alpha.8344773 build "out of the box" on your
>> system? Otherwise, what problems do you encounter, and how (if at all) do you
>> manage to get it to build?
...
> Fails at the ./prebuild.sh in the unix/ directory. This is both on FreeBSD 10.2
> and Debian testing with the official stable 3.7.0.0 build. On both systems I
> get:
...
> So, it's not generating Makefile.in for some reason.
Okay... but how about 3.7.1-alpha.8344773 or later?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/10/2016 01:22 AM, jhu wrote:
> "clipka" <nomail@nomail> wrote:
>> We've been having problems with the Unix build process in the past, often
>> related to the boost libraries. I'm wondering where we're at with these issues
>> right now with the current master branch.
>>
>> If the 3.7 build process has ever failed to work "out of the box" for you (i.e.
>> strictly following the baseline build instructions described in `unix/README`),
>> I'd love to hear from you:
>>
>> - What variant of Unix are you using?
>> - What version of the boost library are you using?
>>
>> - Does the official stable 3.7.0.0 build "out of the box" on your system?
>> Otherwise, what problems do you encounter, and how (if at all) do you manage to
>> get it to build?
>>
>> - Does the current master 3.7.1-alpha.8344773 build "out of the box" on your
>> system? Otherwise, what problems do you encounter, and how (if at all) do you
>> manage to get it to build?
>>
>> - Any other observations?
>>
>>
>> (Please do NOT reply if the 3.7 build process has always worked perfectly fine
>> for you.)
>
> Fails at the ./prebuild.sh in the unix/ directory. This is both on FreeBSD 10.2
> and Debian testing with the official stable 3.7.0.0 build. On both systems I
> get:
>
> configure.ac:302: the top level
> + cat ./configure
> + sed -e 's,configure.gnu --help=recursive,& --srcdir=$ac_srcdir,g' -e 's,\(cd
> \)\($ac_\)\(pop\)*\(dir\),\1"\2\3\4",g' -e
> 's,$am_aux_dir/missing,\\"$am_aux_dir\\"/missing,g'
> + mv -f ./configure.tmp ./configure
> + chmod +x ./configure
> + rm -f -r ./autom4te.cache
> sed: ./Makefile.in: No such file or directory
>
> So, it's not generating Makefile.in for some reason.
>
>
>
Does the suggested fix at the bottom of git issue 54 fix things for your
3.7.0-stable build ?
See: https://github.com/POV-Ray/povray/issues/54
Aside:
-----
Christoph! I believe you can close git issue 54 as that user is
compiling 3.7.0-stable OK.
Also a reminder one of the main reasons for staying with 3.7.0-stable is
the 17-19% performance hit in 3.7.1. My working machines is currently
just a 2 core i3... I confess to not having lately tested performance
for 3.7.1. Have the developers at all addressed the performance issue?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
