In article <web.40fefb25a404e2e24e6ed3100@news.povray.org> , "Tim F" 
<fen### [at] stanfordedu> wrote:

>> No, that argument is nonsensical.
>
> Then you haven't read it carefully enough.  Whats to say the libraries
> packaged with 3.6 are bug free and will not lead to non-povray related
> error reports in the future?
>
>> The decision stands, and no matter how
>> much you or anybody else complain about it, it will *****not***** change.
>
> Irrelevant - we're discussing the reasons for the decision - not an
> imperative to change it.
>
>> If you or anybody else does not like that - we absolutely do not care.
>
> Neither do I, since "liking it" was never any part of my post.  Again, I'm
> just trying to understand the decision, not challenge it.

I already told you.  You did apparently not understand also I was very
elaborate.  I suggest you just accept it as given if you do not understand
the original answer to your original question in this regard.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Tim F <fen### [at] stanfordedu> wrote:
> Then you haven't read it carefully enough.  Whats to say the libraries
> packaged with 3.6 are bug free and will not lead to non-povray related
> error reports in the future?

  You think POV-Ray's building system will always use the bundled libraries
regardless of what's installed in the system?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>
>   You think POV-Ray's building system will always use the bundled libraries
> regardless of what's installed in the system?
>

No - dynamic linking should handle this problem (correct me if I'm wrong).
However, the prepackaged binary is statically linked:

$ file /usr/local/bin/povray
/usr/local/bin/povray: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), for GNU/Linux 2.2.0, statically linked, stripped

seems like it would only use the bundled libraries here, neh?

Regards,
Tim

Post a reply to this message

In article <web.40ff8861a404e2e2300017f40@news.povray.org> , "Tim F" 
<fen### [at] stanfordedu> wrote:

> $ file /usr/local/bin/povray
> /usr/local/bin/povray: ELF 32-bit LSB executable, Intel 80386, version 1
> (SYSV), for GNU/Linux 2.2.0, statically linked, stripped
>
> seems like it would only use the bundled libraries here, neh?

As was already pointed out, users with outdated image support libray
versions would report problems in POV-Ray that were actually due to them
using outdated image support libray versions.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> No - dynamic linking should handle this problem (correct me if I'm wrong).

	Dynamic linking is used for pre-installed libraries which versions
are at least (or above) that of the libraries provided with POV-Ray.  For
instance, if you have an hypothetical libpng-1.3.1 while POV-Ray requires
at least libpng-1.2.5, the POV-Ray binary will be linked with your shared
library libpng-1.3.1.  Otherwise POV-Ray will configure and build the
libpng-1.2.5 sources provided in the package, and statically link with it.
	The console output of configure is quite clear about this.

> However, the prepackaged binary is statically linked

	That should not be the case with the binary you obtained on your
FC2 distro since you said zlib didn't have to build there.  Therefore
at least this library (as well as probably libpng and libjpeg) should be
dynamically linked with the povray binary.  Maybe only libtiff will be
linked statically (assuming FC2 does not ship with the most recent
version of libtiff).

	- NC

Post a reply to this message

> However, the prepackaged binary is statically linked:
> 
> $ file /usr/local/bin/povray
> /usr/local/bin/povray: ELF 32-bit LSB executable, Intel 80386, version 1
> (SYSV), for GNU/Linux 2.2.0, statically linked, stripped
> 
> seems like it would only use the bundled libraries here, neh?

	BTW, having a fully-static binary for the official PC-Linux release
is the only way to go.  We cannot afford tons of "bug" reports from people
unable to run a binary that requires shared libraries they don't necessarily
have on their system.  The advantage of a fully-static binary is much higher
than the potential situation you describe (which can be resolved by installing
instead the POV-Ray source package and the updated 3rd-party libraries).

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> > No - dynamic linking should handle this problem (correct me if I'm wrong).
>
>  Dynamic linking is used for pre-installed libraries which versions
> are at least (or above) that of the libraries provided with POV-Ray.

<snip>

> Maybe only libtiff will be
> linked statically (assuming FC2 does not ship with the most recent
> version of libtiff).
>

I don't think I'm relaying my point properly.  None of this has *anything*
to do with what I was trying to suggest.  As an example, lets say I have
the prepackaged binary, which is statically linked against libpng-1.2.5 (I
think). But lets say there is a bug in libpng-1.2.5 that in certain
instances causes a memory overflow or (even less likely) a corrupted image.
 libpng-1.2.6beta has a fix for this bug, but all users of the prepackaged
povray now have a borked binary.

My point is, end users may then submit bug reports for what is not a povray
related problem.  Thus, the problem that you and Thorsten rightly bring up
(and I fully agree with) has now been effectively reversed.

Again, I realize its splitting hairs and most likely won't be a problem of
any consequence, and I'm sure has already been considered to be of
negligible risk.

Sorry for causing such a stir.

Regards,
Tim

Post a reply to this message

Tim F wrote:
> 
> I don't think I'm relaying my point properly.  None of this has *anything*
> to do with what I was trying to suggest.  As an example, lets say I have
> the prepackaged binary, which is statically linked against libpng-1.2.5 (I
> think). But lets say there is a bug in libpng-1.2.5 that in certain
> instances causes a memory overflow or (even less likely) a corrupted image.
>  libpng-1.2.6beta has a fix for this bug, but all users of the prepackaged
> povray now have a borked binary.

Do you really think we have not been aware of this possibility when 
making the decision to have a statically linked official version?

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

> I don't think I'm relaying my point properly.  None of this has *anything*
> to do with what I was trying to suggest.  As an example, lets say I have
> the prepackaged binary, which is statically linked against libpng-1.2.5 (I
> think). But lets say there is a bug in libpng-1.2.5 that in certain
> instances causes a memory overflow or (even less likely) a corrupted image.
>  libpng-1.2.6beta has a fix for this bug, but all users of the prepackaged
> povray now have a borked binary.

	I was addressing this more specifically in my second message (in the
first one I didn't notice you were actually refering to the official binary
for PC-Linux)  :-)
	Again, this has been considered a minor (and only potential*) problem
with respect to releasing a fully-static binary, which _should_ work in any
circumstance on a not-so-old PC and Linux kernel.  Since the POV-Team does not
develop the 3rd-party libraries, there is of course a risk, but this risk is
evaluated when (publicly beta-)testing the binaries.

	- NC

* IIRC such a situation already happened with POV-Ray 3.1g and the PNG library.

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
>
> Do you really think we have not been aware of this possibility when
> making the decision to have a statically linked official version?
>

No - I never said that.  My question was:

Message: <web.40febe24a404e2e24e6ed3100@news.povray.org>
"Thorsten Froehlich" <thorsten [at] trfde> wrote:
>
> Because many people have extremely outdated versions and the start reporting
> problems in POV-Ray resulting from them having linked POV-Ray with outdated
> obsolete buggy libraries that had been fixed a long time ago.

But what happens when the problem is reversed?  i.e. what if new libraries
appear that fix a bug or two in an external dependency to POVRay?  Will new
point releases of POVRay be released, or should users download the new
libraries and rebuild POVRay, linking to the updated libraries?

Regards,
Tim

Post a reply to this message