On Thu, 27 Mar 2003 17:27:15 EST, "cconstan" <cco### [at] cscuvicca> wrote:
> ok, so it's not a bug. I read the README.unix but not README as they
> traditionally contain very unusful information for Unix people.

This feature is not Unix related. It is necessity for all platforms.

> No, I consider it someone frivolous (sp?) to require the person doing the
> compile to put there name in a macro for crying out loud. I shouldn't have
> to do it at all.

You are responsible for your own compilation since this reflects _your_
knowledge about compiling and sharing habits, _your_ intentions about
influencing other environments (including viruses), configuration of _your_
system. What's wrong with signing your version for these reasons? Imagine, You
will give your (working for You) binaries to somebody and it will not work
there. Who should be first informed - overloaded team or the one who made
binaries ?

ABX

Post a reply to this message

On Fri, 28 Mar 2003, Thorsten Froehlich wrote:
>
>I told you why:
>
>"As a matter of fact the directive
>is there for exactly this reason because in the past countless people did
>not read any documentation and started to distribute unofficial versions of
>POV-Ray that violated the POV-Ray license."
>
>The license requires that you provide the information your are supposed to
>enter there if you want to distribute the version you compiled.
>
>    Thorsten

  I have just read this thread and am filled with the urge to ask the same
  question that I have asked many times before :

	Why is there no Official build for Solaris?

  In the past I have exchanged emails with Mark Gordon on this topic and
  the answer is generally the same every time : you need the Sun hardware.

  I agree that you need the Sun hardware and, far more importantly, the
  correct and professional development tools to build the binaries in such
  a way that they run well on the Intel Pentium revisions as well as the
  Sun Sparc processor revisions.  You can not achieve reasonable optimization
  with gcc and I think this fact has been very well demonstrated.

  I have wanted to build a correct and optimized build of POV-Ray for quite
  some time.  Building the previous revisions was no big deal but the latest
  rev caused me some issues.  Yes, I am sure that I can build it in its most
  recent edition but that is not the point.  Why is there no official version?

  Before you answer that quation with "I don't have Sun hardware and Forte
  compiler tools" may I suggest that you have a close look at the website
  at www.blastwave.org ?  You will note that an entire Sun Solaris development
  lab has been built there in which ALL the hardware and software required is
  provided to the user for free.  All they need to do is drop me a line with
  a proposal for the project that they will work on.  When done, the software
  will be bundled up as a correctly built Sun Solaris software package and
  then distributed by blastwave.org to the Sun user community.  Since I have
  built and funded the site, and Sun Microsystems is behind me on this, why
  is there no official build for POV-Ray for Solaris?

  Sun users want POV-Ray and Sun people, both internal and external, would be
  happy to help you with it.

  After all, doesn't POV-Ray deserve to be chewing up CPU cycles at every big
  Sun server farm all over the world?  :)

	Dennis M. Clarke
	Sponsor, Owner and Admin for
	CSW - Community Software for Solaris
	http://www.blastwave.org/

Post a reply to this message

In article <Pine.GSO.4.53.0303301152250.15852@blastwave> , Dennis Clarke 
<dcl### [at] blastwaveorg>  wrote:

>   I have just read this thread and am filled with the urge to ask the same
>   question that I have asked many times before :
>
>  Why is there no Official build for Solaris?

The team has one maintainer for every platform with official support.  And
official versions require official support.  Which requires detailed
knowledge about the system being supported.  It is more than just compiling
POV-Ray.  So we just follow a conservative approach in not making official
versions available we cannot promise we will be able to support.  There is
nothing keeping from anybody else making unofficial versions available.  In
essence, official support is the only difference between official compiles
and unofficial compiles of the official source code.

>   In the past I have exchanged emails with Mark Gordon on this topic and
>   the answer is generally the same every time : you need the Sun hardware.

Indeed, without it is hard.  Of course, those are easy to get access to for
some people, but access and time are two different stories ;-)

>   I have wanted to build a correct and optimized build of POV-Ray for quite
>   some time.  Building the previous revisions was no big deal but the latest
>   rev caused me some issues.  Yes, I am sure that I can build it in its most
>   recent edition but that is not the point.

Well, the build issues on various non-Linux Unix versions are being
addressed, and some pieces of it (like 64 bit compatibility) will be
available in 3.51 source code.  It will only get easier to compile and run
POV-Ray on multiple Unix platforms in the future.

>   Since I have
>   built and funded the site, and Sun Microsystems is behind me on this, why
>   is there no official build for POV-Ray for Solaris?

Well, just having the hardware and software obviously isn't enough for an
officially supported version as pointed out above.  There is more to it, and
there is also a "political" aspect: Once we soften our stand of when a
compile is official, we also get users of other platforms asking for the
same.

The users of Power, MIPS, PA-RISC or Alpha based systems with their
multitude of Unix (-like) systems will want their official version as well.

>   After all, doesn't POV-Ray deserve to be chewing up CPU cycles at every big
>   Sun server farm all over the world?  :)

Well, given that the POV-Ray 3.x does not support multithreading or any
other means of easy way to run efficiently on multiprocessor systems with
all features working, there isn't too much point to it.  Otherwise I would
really love to run compile and run POV-Ray on this
<http://www.rz.rwth-aachen.de/hpc/SUN/index_e.html> baby at my current
university assuming I would find the time next to graduate studies ;-)

So it is not lack of interest that prevents an official version, but it is
lack of feasibility taking into account all of the various issues I pointed
out above.

Sorry!

    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

> Otherwise I would
> really love to run compile and run POV-Ray on this
> <http://www.rz.rwth-aachen.de/hpc/SUN/index_e.html> baby at my current
> university assuming I would find the time next to graduate studies ;-)

	Wow, this baby still ranks #173 at top500.org, so maybe you should
give it a try  ;-)  I don't remember if there is a MPI compile of the last
POV-Ray 3.50c, for I would use it on our Helics cluster (#64, that's nearly
the fastest Linux cluster in Germany and Europe)...

	Geeee can't find any MPI version of 3.5 on the povray links {sigh}
	Mmmh, should be something to consider in my TODO list for 3.51  ;-)

	- NC

Post a reply to this message

On Sun, 30 Mar 2003, Thorsten Froehlich wrote:
>In article <Pine.GSO.4.53.0303301152250.15852@blastwave> , Dennis Clarke
><dcl### [at] blastwaveorg>  wrote:
>
>>   I have just read this thread and am filled with the urge to ask the same
>>   question that I have asked many times before :
>>
>>  Why is there no Official build for Solaris?
>
>The team has one maintainer for every platform with official support.  And
>official versions require official support.  Which requires detailed
>knowledge about the system being supported.  It is more than just compiling
>POV-Ray.  So we just follow a conservative approach in not making official
>versions available we cannot promise we will be able to support.  There is
>nothing keeping from anybody else making unofficial versions available.  In
>essence, official support is the only difference between official compiles
>and unofficial compiles of the official source code.

  In that case I guess it will be OK for the people at www.blastwave.org to
  go ahead and package up POV-Ray for Solaris and then release that build
  to the Solaris community as an unofficial build.

>
>>   In the past I have exchanged emails with Mark Gordon on this topic and
>>   the answer is generally the same every time : you need the Sun hardware.
>
>Indeed, without it is hard.  Of course, those are easy to get access to for
>some people, but access and time are two different stories ;-)

  Thankfully the blastwave crew has a membership full of die-hard Sun types
  that can easily program their way through the builds.  I don't expect that
  we will change the code unless there are valid reasons to avoid compiler
  warnings or errors.

>
>>   I have wanted to build a correct and optimized build of POV-Ray for quite
>>   some time.  Building the previous revisions was no big deal but the latest
>>   rev caused me some issues.  Yes, I am sure that I can build it in its most
>>   recent edition but that is not the point.
>
>Well, the build issues on various non-Linux Unix versions are being
>addressed, and some pieces of it (like 64 bit compatibility) will be
>available in 3.51 source code.  It will only get easier to compile and run
>POV-Ray on multiple Unix platforms in the future.

  I see that there has been work done in that area and with luck POV-Ray will
  post respectable performance numbers while being consistent across the
  different architectures.

>
>>   Since I have
>>   built and funded the site, and Sun Microsystems is behind me on this, why
>>   is there no official build for POV-Ray for Solaris?
>
>Well, just having the hardware and software obviously isn't enough for an
>officially supported version as pointed out above.  There is more to it, and
>there is also a "political" aspect: Once we soften our stand of when a
>compile is official, we also get users of other platforms asking for the
>same.

  I agree and see your point clearly.

>
>The users of Power, MIPS, PA-RISC or Alpha based systems with their
>multitude of Unix (-like) systems will want their official version as well.
>
>>   After all, doesn't POV-Ray deserve to be chewing up CPU cycles at every big
>>   Sun server farm all over the world?  :)
>
>Well, given that the POV-Ray 3.x does not support multithreading or any
>other means of easy way to run efficiently on multiprocessor systems with
>all features working, there isn't too much point to it.  Otherwise I would
>really love to run compile and run POV-Ray on this
><http://www.rz.rwth-aachen.de/hpc/SUN/index_e.html> baby at my current
>university assuming I would find the time next to graduate studies ;-)

 Ah yes, the old multi-threading issue that has haunted POVRay users for many
 years.  I think that a complete rewrite of the code would be required to get
 POV-Ray to dispatch POSIX compliant worker threads.  The thread model problem
 is a big one when one considers that you support Windows and Linux.  One can
 only shudder at the work load required to make POV-Ray a multithreaded ray
 tracing engine.

>
>So it is not lack of interest that prevents an official version, but it is
>lack of feasibility taking into account all of the various issues I pointed
>out above.
>
>Sorry!

  Hey, I can always built it myself!

  Thanks for the quick reply :)

 Dennis Clarke
 dcl### [at] blastwaveorg

Post a reply to this message

In article <3E8### [at] freefr> , Nicolas Calimet <pov### [at] freefr>
wrote:

>  Wow, this baby still ranks #173 at top500.org, so maybe you should
> give it a try  ;-)

Yes, it should be back in the top 50 this summer... :-)

    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

Well .. I am now working on an "Official Release of POV-Ray" from
blastwave.org which will be a Un-Official Release from the POV-Ray team and
will be clearly marked as such.

However ... first kick at this big electric cat results in :

bash-2.03$ ./configure --prefix=/opt/csw
.
. all good stuff ...
.

bash-2.03$ make
Making all in doc
Making all in html
Making all in images
Making all in vfaq
make: Fatal error: Don't know how to make target `skysphe'
Current working directory
/export/medusa/dclarke/build/sparc/povray-3.50c/doc/html/images
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory
/export/medusa/dclarke/build/sparc/povray-3.50c/doc/html/images
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory
/export/medusa/dclarke/build/sparc/povray-3.50c/doc/html
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /export/medusa/dclarke/build/sparc/povray-3.50c/doc
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'

.. yep .. that's what I expected.

 Once I get this thing built for Sparc 32-bit and 64-bit and Intel I will
 package it up and release on www.blastwave.org.  It will probably end up
 on the Sun Companion Software CD which ships with the Solaris 9 and 10
 media kits.

 when I get it working ...  ;)

 dennis

 dcl### [at] blastwaveorg

Post a reply to this message

Just want to let you know that I have side-slipped the doc SUBDIR also and
have not hit a tiff problem, but, be thankful that you were using gcc to do
the compile as the Forte 6U2 compilers and tools have a fit with those
Makefiles!

thus :

Making all in src
gmake[1]: Entering directory
`/export/medusa/dclarke/build/sparc/povray-3.50c/src'
c++ -DPREFIX=\"/opt/csw\" -DPOV_LIB_DIR=\"/opt/csw/share/povray-3.5\"
-DCOMPILER_VER=\".Linux.cc\" -DSYSCONFDIR=\"/opt/csw/etc\"
-DUSE_IO_RESTRICTIONS=\"\"   -I/opt/csw/include  `if [ "Xcc" = "Xgcc" ]; then
echo "-Wno-multichar"; fi ` -O3 -finline-functions -ffast-math
-fomit-frame-pointer -funroll-loops -fexpensive-optimizations -malign-double
-foptimize-sibling-calls -minline-all-stringops -Wno-multichar -c atmosph.cpp
cc1plus: Invalid option `align-double'
cc1plus: Invalid option `inline-all-stringops'
cc1plus: Invalid option `-foptimize-sibling-calls'
gmake[1]: *** [atmosph.o] Error 1
gmake[1]: Leaving directory
`/export/medusa/dclarke/build/sparc/povray-3.50c/src'
gmake: *** [all-recursive] Error 1

--------- foobar options for real Sun/Forte cc -------------

What I am doing is doing a find for every Makefile that has been created and
then manually edited them ( there are 73 Makefiles ) such that the CFLAGS are
correct for Sun/Forte with a few basic optimizations.

  fun fun fun ...  :-P

Dennis Clarke
dcl### [at] blastwaveorg

Post a reply to this message

In article <Pine.GSO.4.53.0303302337490.25621@blastwave> , Dennis Clarke 
<dcl### [at] blastwaveorg>  wrote:

> 64-bit

be aware that you cannot build a fully working 64 bit version of POV-Ray
3.50 without source code changes.

    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

On Mon, 31 Mar 2003, Thorsten Froehlich wrote:
>In article <Pine.GSO.4.53.0303302337490.25621@blastwave> , Dennis Clarke
><dcl### [at] blastwaveorg>  wrote:
>
>> 64-bit
>
>be aware that you cannot build a fully working 64 bit version of POV-Ray
>3.50 without source code changes.
>
>    Thorsten

  thank you for the alert, you probably saved me a lot of time.

 At the moment I have a few library problems and the compiler issues a million
warnings about multi-byte constants.  Not exactly portable code.

 in any case .. I had it running at about 02:00AM last night but it was dog
 slow on the UltraSparc.  I trying to render the benchmark.pov with -Q9 and
 a number of other options that were not in the readme section of the
benchmark.pov scene file.  That was a mistake.  It took an hour for the first
 50 pixel lines of a 640x480 image.  Not so good.  It also used up 15Mb of
memory to generate that sort of performance.

 I have more than a few hours of work ahead of me I see ...

 Item number 6 below is a real problem.  That should not be there.

 Dennis

--------------------------------------------------------------------
bash-2.03$ dump -Lv src/povray

src/povray:

  **** DYNAMIC SECTION INFORMATION ****
.dynamic:
[INDEX] Tag         Value
[1]     NEEDED          libtiff.so
[2]     NEEDED          libjpeg.so.62
[3]     NEEDED          libpng.so.3
[4]     NEEDED          libz.so.1
[5]     NEEDED          libX11.so.4
[6]     NEEDED          libstdc++.so.2.10.0
[7]     NEEDED          libm.so.1
[8]     NEEDED          libc.so.1
[9]     INIT            0xf51cc
[10]    FINI            0xf51e8
[11]    RUNPATH         /opt/csw/lib:/usr/openwin/lib
[12]    RPATH           /opt/csw/lib:/usr/openwin/lib
[13]    HASH            0x100e8
[14]    STRTAB          0x18d78
[15]    STRSZ           0x9549
[16]    SYMTAB          0x12fc8
[17]    SYMENT          0x10
[18]    CHECKSUM        0xb00f
[19]    VERNEED         0x222c4
[20]    VERNEEDNUM      0x4
[21]    PLTSZ           0x894
[22]    PLTREL          0x7
[23]    JMPREL          0x22398
[24]    RELA            0x22344
[25]    RELASZ          0x8e8
[26]    RELAENT         0xc
[27]    DEBUG           0
[28]    FEATURE_1       PARINIT
[29]    FLAGS           0
[30]    FLAGS_1         0
[31]    PLTGOT          0x119934

Post a reply to this message