Is there a comprehensive list of development libraries required to
compile POV-Ray 3.7+ in its *entirety?*

I've already had to recompile all of my 3.7+ executables /several/
times, in one case because POV-Ray compiled to completion even though a
prereq dev library was among those yanked away by a distro upgrade.  And
now, after ONCE AGAIN pulling my hair out for way too long trying to
figure out another informative "Problem with option setting / Failed to
parse command-line option" message, I discover that POV-Ray compiled
cleanly with no EXR capability.

My first idea was to check the messages for the list of libraries used,
but it only lists the libraries that are on the system.  I've now
installed the ILM dev library, but I don't want to waste /another/ few
days re-compiling POV-Ray versions, only to find that it silently
skipped another missing library, meaning I would have to waste anothe
few days compiling /again./  Is there a list of *everything* required
for a *complete* compile?

Or at least reconfigure POV-Ray so that it doesn't compile with half its
capabilities  missing?

These are the libraries listed by a POV-Ray run.  I notice that SDL
isn't on this list.  (Thanks, Bill, for pointing out a requirement that
I would *never* have been able to find out.)  Are there any others
besides ILM that are missing?
  ZLib 1.2.11
  LibPNG 1.6.34
  LibJPEG 80
  LibTIFF 4.0.9
  Boost 1.66

Speaking of which, why did I have to recompile anything in the first
place?  I didn't have to recompile 3.5 or 3.6 or MegaPOV.  But POV-Ray
3.7, 3.8-beta, the master branch, and UberPOV all choked on incompatible
library versions, for more than one upgrade.  Is there some way to build
POV-Ray for Unix/Linux so that I don't have to recompile the damn things
every time I do an OS upgrade?  This is not a workable system!

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> Is there a comprehensive list of development libraries required to
> compile POV-Ray 3.7+ in its *entirety?*
>
> I've already had to recompile all of my 3.7+ executables /several/
> times, in one case because POV-Ray compiled to completion even though a
> prereq dev library was among those yanked away by a distro upgrade.  And
> now, after ONCE AGAIN pulling my hair out for way too long trying to
> figure out another informative "Problem with option setting / Failed to
> parse command-line option" message, I discover that POV-Ray compiled
> cleanly with no EXR capability.
>
> My first idea was to check the messages for the list of libraries used,
> but it only lists the libraries that are on the system.  I've now
> installed the ILM dev library, but I don't want to waste /another/ few
> days re-compiling POV-Ray versions, only to find that it silently
> skipped another missing library, meaning I would have to waste anothe
> few days compiling /again./  Is there a list of *everything* required
> for a *complete* compile?
>
> Or at least reconfigure POV-Ray so that it doesn't compile with half its
> capabilities  missing?
>
> These are the libraries listed by a POV-Ray run.  I notice that SDL
> isn't on this list.  (Thanks, Bill, for pointing out a requirement that
> I would *never* have been able to find out.)  Are there any others
> besides ILM that are missing?
>   ZLib 1.2.11
>   LibPNG 1.6.34
>   LibJPEG 80
>   LibTIFF 4.0.9
>   Boost 1.66
>
> Speaking of which, why did I have to recompile anything in the first
> place?  I didn't have to recompile 3.5 or 3.6 or MegaPOV.  But POV-Ray
> 3.7, 3.8-beta, the master branch, and UberPOV all choked on incompatible
> library versions, for more than one upgrade.  Is there some way to build
> POV-Ray for Unix/Linux so that I don't have to recompile the damn things
> every time I do an OS upgrade?  This is not a workable system!

I have the same conundrum. I tinker with my Ubuntu-based distro constantly so
recompiling povray is second nature now. This is my install loadout on Lubuntu:

sudo apt install libboost-thread-dev libjpeg-dev libpng-dev libtiff-dev
libsdl1.2-dev openexr

The libboost-thread-dev pulls in zlib automatically so no need to include it.
The other change I make is ./configure --prefix=/home/jeff/.local to put
everything in my personal directory. No need to swap permissions to hack on any
part of it then.

For "compile once, run somewhere else", if you feel handy you could do an
AppImage,
Flatpak or snap package. Getting any of them set up is a bit of a PITA but once
you're set up, your there.

Cheers.

Post a reply to this message

On 21-10-08 9:20 PM (-4), The Traveler wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>>
>> These are the libraries listed by a POV-Ray run.  I notice that SDL
>> isn't on this list.  (Thanks, Bill, for pointing out a requirement that
>> I would *never* have been able to find out.)  Are there any others
>> besides ILM that are missing?
>>   ZLib 1.2.11
>>   LibPNG 1.6.34
>>   LibJPEG 80
>>   LibTIFF 4.0.9
>>   Boost 1.66
>>
>> Speaking of which, why did I have to recompile anything in the first
>> place?  I didn't have to recompile 3.5 or 3.6 or MegaPOV.  But POV-Ray
>> 3.7, 3.8-beta, the master branch, and UberPOV all choked on incompatible
>> library versions, for more than one upgrade.  Is there some way to build
>> POV-Ray for Unix/Linux so that I don't have to recompile the damn things
>> every time I do an OS upgrade?  This is not a workable system!
> 
> I have the same conundrum. I tinker with my Ubuntu-based distro constantly so
> recompiling povray is second nature now. This is my install loadout on Lubuntu:
> 
> sudo apt install libboost-thread-dev libjpeg-dev libpng-dev libtiff-dev
> libsdl1.2-dev openexr

So it looks like OpenEXR was the last library that I didn't have.  N.B.
I also had to install openexr-devel to get EXR to work in POV-Ray.

> The libboost-thread-dev pulls in zlib automatically so no need to include it.
> The other change I make is ./configure --prefix=/home/jeff/.local to put
> everything in my personal directory. No need to swap permissions to hack on any
> part of it then.

I'll remember this if I ever decide to install POV-Ray on my phone.

> For "compile once, run somewhere else", if you feel handy you could do an
> AppImage,
> Flatpak or snap package. Getting any of them set up is a bit of a PITA but once
> you're set up, your there.

Great.  After Git making my life easier, all I need is another PITA; but
if one of these works, then it really will make my life easier.  Thanks!

Post a reply to this message

hi,

"The Traveler" <jho### [at] northrimnet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> > ... in one case because POV-Ray compiled to completion even though a
> > prereq dev library was among those yanked away by a distro upgrade.
> > ...
> > Speaking of which, why did I have to recompile anything in the first
> > place?  I didn't have to recompile 3.5 or 3.6 or MegaPOV.  But POV-Ray
> > 3.7, 3.8-beta, the master branch, and UberPOV all choked on incompatible
> > library versions, for more than one upgrade.  Is there some way to build
> > POV-Ray for Unix/Linux so that I don't have to recompile the damn things
> > every time I do an OS upgrade?  This is not a workable system!
>
> I have the same conundrum. I tinker with my Ubuntu-based distro constantly so
> recompiling povray is second nature now. This is my install loadout on Lubuntu:

could either (or both) of you using the "wrong" command sequence when
updating/upgrading?  not familiar enough with 'apt' but the package manager
definitely should be able to add a new library without removing an existing; for
instance, I have libpng libraries for three versions on the same machine -- that
is what .so version numbers are for.


> > So it looks like OpenEXR was the last library that I didn't have.  N.B.
> > I also had to install openexr-devel to get EXR to work in POV-Ray.

"sane" operating environments do not split packages into -dev, -doc, whatever.
;-)


regards, jr.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> writes:

> Is there a comprehensive list of development libraries required to
> compile POV-Ray 3.7+ in its *entirety?*

On Debian based system, POV-Ray is available as a package - but of
course that's always some version considered "stable".  This is helpful,
though:

When I set up to compile 3.8 beta, I looked at the dependencies of the
binary package - and then installed the header files for each of them.
Look for the same name followed by -dev.  If you use the names _without_
a version number (e.g. libboost-thread-dev instead of
libboost-thread1.67-dev), then OS upgrades should give you always the
"recent" version for your platform.

You can see the list either with your package manager, or online:
https://packages.debian.org/bullseye/povray

My compilation of POV-Ray 3.8.0-beta.2.unofficial went quite nice from
there.
-- 
Cheers,
haj

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "The Traveler" <jho### [at] northrimnet> wrote:
> > Cousin Ricky <ric### [at] yahoocom> wrote:
> > > ... in one case because POV-Ray compiled to completion even though a
> > > prereq dev library was among those yanked away by a distro upgrade.
> > > ...
> > > Speaking of which, why did I have to recompile anything in the first
> > > place?  I didn't have to recompile 3.5 or 3.6 or MegaPOV.  But POV-Ray
> > > 3.7, 3.8-beta, the master branch, and UberPOV all choked on incompatible
> > > library versions, for more than one upgrade.  Is there some way to build
> > > POV-Ray for Unix/Linux so that I don't have to recompile the damn things
> > > every time I do an OS upgrade?  This is not a workable system!
> >
> > I have the same conundrum. I tinker with my Ubuntu-based distro constantly so
> > recompiling povray is second nature now. This is my install loadout on Lubuntu:
>
> could either (or both) of you using the "wrong" command sequence when
> updating/upgrading?  not familiar enough with 'apt' but the package manager
> definitely should be able to add a new library without removing an existing; for
> instance, I have libpng libraries for three versions on the same machine -- that
> is what .so version numbers are for.
>
>
> > > So it looks like OpenEXR was the last library that I didn't have.  N.B.
> > > I also had to install openexr-devel to get EXR to work in POV-Ray.
>
> "sane" operating environments do not split packages into -dev, -doc, whatever.
> ;-)
>
>
> regards, jr.

Hi jr,
" ... could either (or both) of you using the "wrong" command sequence when
updating/upgrading?"

Nah. I've been a linux user (hacker) since Slackware back in '95 (I built my
first company, an Internet Service Provider, on it in that same year). I just
break stuff. I do a lot of kernel and driver hacking and generally end up at
some point with a borked system. I also like to investigate the pre-release
stuff in non-LTS distro releases and chase down bugs.

""sane" operating environments do not split packages into -dev, -doc, whatever."

Heh, they do in my book. Why would one need all the development code and the
docs for it if all they were doing is end-user stuff? That's why Windows was
created ... ;)

Cheers.

Post a reply to this message

hi,

"The Traveler" <jho### [at] northrimnet> wrote:
> ...
> Nah. I've been a linux user (hacker) since Slackware back in '95 (I built my
> first company, an Internet Service Provider, on it in that same year). I just
> break stuff. I do a lot of kernel and driver hacking and generally end up at
> some point with a borked system. I also like to investigate the pre-release
> stuff in non-LTS distro releases and chase down bugs.

nice.  self prefers stability, and (dependable) up-time[*], hence still a
Slackware user, for all my sins ;-).  I will compile my kernels and a sub-set of
libraries and applications to suit, but no .. experiments.

[*] one 14.2 system passed 1K days up-time recently.  :-)


>> ""sane" operating environments do not split packages into -dev, -doc, whatever."
> Heh, they do in my book. Why would one need all the development code and the
> docs for it if all they were doing is end-user stuff? That's why Windows was
> created ... ;)

exactly.  different worlds.  personally, switched to a Chromebook for my "always
up-to-date online experience", quite happy with that.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "The Traveler" <jho### [at] northrimnet> wrote:
> > ...
> > Nah. I've been a linux user (hacker) since Slackware back in '95 (I built my
> > first company, an Internet Service Provider, on it in that same year). I just
> > break stuff. I do a lot of kernel and driver hacking and generally end up at
> > some point with a borked system. I also like to investigate the pre-release
> > stuff in non-LTS distro releases and chase down bugs.
>
> nice.  self prefers stability, and (dependable) up-time[*], hence still a
> Slackware user, for all my sins ;-).  I will compile my kernels and a sub-set of
> libraries and applications to suit, but no .. experiments.
>
> [*] one 14.2 system passed 1K days up-time recently.  :-)
>
>
> >> ""sane" operating environments do not split packages into -dev, -doc, whatever."
> > Heh, they do in my book. Why would one need all the development code and the
> > docs for it if all they were doing is end-user stuff? That's why Windows was
> > created ... ;)
>
> exactly.  different worlds.  personally, switched to a Chromebook for my "always
> up-to-date online experience", quite happy with that.
>
>
> regards, jr.

" ...personally, switched to a Chromebook for my "always > up-to-date online
experience", quite happy with that."

Been giving it a thought myself recently. I'm a card-carrying Firefox and
Thunderbird user and I know that Chrome is favored. Well, as comparitivly
inexpensive as they are, I may end up with one and put some flavor of Linux on
it. ;)

Post a reply to this message

hi,

"The Traveler" <jho### [at] northrimnet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ... Chromebook ...
> Been giving it a thought myself recently. I'm a card-carrying Firefox and
> Thunderbird user and I know that Chrome is favored. Well, as comparitivly
> inexpensive as they are, I may end up with one and put some flavor of Linux on
> it. ;)

Chromebooks with Intel h/ware have a Debian/Ubuntu VM pre-installed, so you
should be able to just copy the Thunderbird profile after installing it.  note,
I would have written "very happy with it" had I had the foresight to buy a model
with more internal storage :-).


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "The Traveler" <jho### [at] northrimnet> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > ... Chromebook ...
> > Been giving it a thought myself recently. I'm a card-carrying Firefox and
> > Thunderbird user and I know that Chrome is favored. Well, as comparitivly
> > inexpensive as they are, I may end up with one and put some flavor of Linux on
> > it. ;)
>
> Chromebooks with Intel h/ware have a Debian/Ubuntu VM pre-installed, so you
> should be able to just copy the Thunderbird profile after installing it.  note,
> I would have written "very happy with it" had I had the foresight to buy a model
> with more internal storage :-).
>
>
> regards, jr.

"Chromebooks with Intel h/ware have a Debian/Ubuntu VM pre-installed". Thanks,
good to know. The last articles I read were from a few years back when they were
still Chromium only. Those were the days when I considered developing Android
apps ... Cheers.

Post a reply to this message