POV-Ray : Newsgroups : povray.binaries.programming : An updated povr tarball for Unix/Linux. f6b1c13e : Re: An updated povr tarball for Unix/Linux. f6b1c13e Server Time
25 Apr 2024 15:29:12 EDT (-0400)
  Re: An updated povr tarball for Unix/Linux. f6b1c13e  
From: William F Pokorny
Date: 20 Jul 2020 20:52:57
Message: <5f163c69$1@news.povray.org>
On 7/20/20 8:54 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Please find attached an updated tarball.
> 
> thanks.  compiles.  will properly make + install sometime later this week.
> 
> one thing I noticed, 'povr' links against an older version of libpng, unlike the
> "stock" POV-Ray.
> 
> jr@swift:13:~$ ldd /usr/local/bin/povray-3.8.0-alpha.10064268
>      ...
>      libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6cc19c5000)
>      ...
> jr@swift:14:~$ ldd POVr/bin/povray2
>      ...
>      libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fb50195f000)
>      ...
> jr@swift:15:~$
> 
> the updated version too links to 1.2.50, when 1.6.37 is available.

Interesting find. :-) Unsure why you see a difference in library used.

It's my understanding when there are multiple versions of a library in 
place on a system there is usually a sym link established from a generic 
name to the 'official' one for the particular linux distribution. It 
would be normal then for the official distribution version to be picked 
up first. This is not necessarily the newest (or oldest) one if you have 
multiple development library versions on a system(1).

(1) - Not all that common, but certainly happens. I have only one libpng 
version on my Ubuntu 18.04 system.

There are certainly ways to override which library gets picked up 
explicitly. Hmm, wonder, if you've got multiple libraries and no symlink 
to a version-less name like libpng.so.1 I'm unsure how one library would 
be picked over another? Do you have the common sym link name given you 
have two libpngs?

> 
>> Attempting no lower case #declare, #local identifier idea. Hope is
>> user's function and macro arguments made _<lower case> form will be
>> immune to name collisions.
> 
> (crestfallen..)  hope 'a_' will be as acceptable as '_a'.
> 

Sure. You can continue to use any names you want for function and macro 
parameters. The _<lower> is the suggestion because it won't collide with 
future SDL keywords where some other lower case string might eventually 
- though probably not a_ :-).

Bill P.


Post a reply to this message

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