"Thorsten Froehlich" <tho### [at] trfde> writes:
>> Yeesh, quit it with the clueless flames.
>
> I think it is you who is clueless here.  Did you ever check out what junk
> Debian distributes a "stable" or "testing" povray packages.  Their "stable
> version is a seven year outdated version of POV-Ray with more broken and
> incompatible patches than POV-Ray has lines of code.  Their "testing"
> version is not a tiny bit better, and there is no serious interest in
> correcting it either.

The quality of packages depends on the package maintainer; for major
packages (gcc, X, etc), debian's maintainers are second to none.  I have
no idea what's up with the povray package, but Debian is a free software
distro, and Povray is _not free software_, so what do you really expect?

Hey, I use Povray, and run Debian (on several machines); I certainly
wish the Povray package would get a bit of love!

> If I would dare to install Debian anywhere, I am sure I would quickly find
> that most of their packages enjoy the same kind of improvements.  And this
> thread regarding gcc problems pretty much emphasizes this point perfectly!

So you've never actually used Debian then?  Do you have any actual
_evidence_ that the gcc problems in this thread have anything to do with
a Debian patch, or of the systemic problems you accuse them of?  Or are
you just randomly spewing wild-ass generalizations because you're pissed
over the state of the Povray package?

Every GNU/linux user that I know runs Debian, for good reason:  It's
more functional, more solid, and _far_ easier to administer than most
other distros, and upholds the ideals of free software better than all.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Post a reply to this message

BTW, I should add:  amd64 is not yet a real Debian architecture, so I'm
not sure what the state of the Debian amd64 port is.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Post a reply to this message

> That's the point of course -- _all_ distros patch their software.
> Sometimes this causes problems (as the infamous redhat "gcc 2.96" case),
> but usually it's for good reaons (otherwise they wouldn't do it).
> Debian is no different.

	The usual patching you're talking about -- and which is _not_
always done in all distros at all, I'd say mostly in "big" ones --
is neither making a heavily-patched CVS snapshot* (gcc 2.96) nor
adding some unstable/incomplete/problematic "features" or "bug-
fixes" (as for the POV-Ray 3.5 in Debian woody/sarge/sid).

	Moreover it'd be a much better idea for the Debian maintainer
of the povray package to switch to 3.6.x rather than messing around**
with the 3.50c build system.  I can't understand that even the Debian
"unstable" (sid) still sticks to 3.50c.  (Anyway I don't care much if
others waste their time "fixing" completely outdated sources...)

	- NC

*  I'm pretty sure you know this story very well
**
http://packages.debian.org/changelogs/pool/non-free/p/povray-3.5/povray-3.5_3.5.0c-10/changelog

Post a reply to this message

>
http://packages.debian.org/changelogs/pool/non-free/p/povray-3.5/povray-3.5_3.5.0c-10/changelog


	Okay, to be fair with the Debian povray maintainer: the official 3.6 sources
were not yet released as of May 2004  :-p  Still, that does not change my point about
Debian "policy" in general.

	- NC

Post a reply to this message

> and Povray is _not free software_, so what do you really expect?

	POV-Ray's licenses are not OSI-compatible, yet POV-Ray is
provided with full source code, so I don't see how it could prevent
anyone to "decently" support it in their distros.

> Do you have any actual
> _evidence_ that the gcc problems in this thread have anything to do with
> a Debian patch, or of the systemic problems you accuse them of?

	In fact, it is a problem with vanilla gcc 3.3.4 on the AMD64.
But the fact that gcc 3.4.x (which _does_ compile POV-Ray on the AMD64)
gives the same ICE on a Debian AMD64 install is quite suspicious...
Either the user or the system is in fault.  For some reason I suspect
the system is the answer  ;-)

> Every GNU/linux user that I know runs Debian, for good reason:  It's
> more functional, more solid, and _far_ easier to administer than most
> other distros, and upholds the ideals of free software better than all.

	More
- functional: no idea
- more solid: I wonder
- easier to administrate than most other distros: not with outdated
softwares I believe.

	OTOH I'm using Knoppix 3.4 without fear (don't tell me it's
based on Debian -- that is not the same thing at all, it's a completely
different distro anyway).

	- NC

Post a reply to this message

In article <87h### [at] tc-1-100kawasakigolnejp> , Miles Bader 
<mil### [at] gnuorg>  wrote:

> The quality of packages depends on the package maintainer; for major
> packages (gcc, X, etc), debian's maintainers are second to none.  I have
> no idea what's up with the povray package, but Debian is a free software
> distro, and Povray is _not free software_, so what do you really expect?

In the narrow definition by a small group that monopolises the term "free
software"? - Hardly a any argument for distributing source code and binaries
that are known to be broken!

> So you've never actually used Debian then?

Why would I, if I can easily read in their package list that all packages
they ship as stable is completely outdated?  To hunt for updates for weeks?

> Do you have any actual
> _evidence_ that the gcc problems in this thread have anything to do with
> a Debian patch, or of the systemic problems you accuse them of?

It works on other Linux systems but not on at least this Debian system.

> Every GNU/linux user that I know runs Debian,

Then you clearly do not know many who actually try to use their system on a
day to day basis for serious work.  Everybody I know who used Debian threw
it out years ago because of the package problems.

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
> Did you ever check out what junk
> Debian distributes a "stable" or "testing" povray packages.  Their "stable
> version is a seven year outdated version of POV-Ray with more broken and
> incompatible patches than POV-Ray has lines of code.  Their "testing"
> version is not a tiny bit better, and there is no serious interest in
> correcting it either.

  And these are people who think "a >> 8" will give a different result
in systems with different endianess and is thus not portable between
platforms.
  If they know so little about basic C standards, I would not be very eager
to trust their code.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:41528eb6@news.povray.org...
> Thorsten Froehlich <tho### [at] trfde> wrote:
> > Did you ever check out what junk
> > Debian distributes a "stable" or "testing" povray packages.  Their
"stable
> > version is a seven year outdated version of POV-Ray with more broken and
> > incompatible patches than POV-Ray has lines of code.  Their "testing"
> > version is not a tiny bit better, and there is no serious interest in
> > correcting it either.
>
>   And these are people who think "a >> 8" will give a different result
> in systems with different endianess and is thus not portable between
> platforms.
>   If they know so little about basic C standards, I would not be very
eager
> to trust their code.
>

slightly o-t, but having never had to consider endian-ness in programs due
to hardly ever using bit level operators. i always just assumed that you
would have to use a >> 8 on some machines and a << 8 on other machines
(though honestly it's something i never really think about)

ya learn something everyday... hopefully. maybe it's about time i buy K&R's
C book. just for the details i've missed thoughout.

thanks.

Post a reply to this message

Ross <rli### [at] everestkcnet> wrote:
> slightly o-t, but having never had to consider endian-ness in programs due
> to hardly ever using bit level operators. i always just assumed that you
> would have to use a >> 8 on some machines and a << 8 on other machines
> (though honestly it's something i never really think about)

  "a >> 8" is standardized to mean that 'a' is shifted so that the
eight least significant bits disappear and the 9th least significant
bit becomes the least significant one and so on.
  That is, if the system uses the 2's complement representation of
integers, "a >> 8" is equivalent to "a / 256".
  This has nothing to do with endianess.

  Even if in one system the machine opcode to do this would be
"shift right" and in another it's "shift left" (which afaik is not
the case in any system: afaik in all systems the shift operation
which decreases the number is called "shift right") there wouldn't
be any problem in making the C compiler perform the proper shift
operation for the >> operator.

  Trying to make the code "portable" by changing shifting operators
depending on the endianess of the target system will only break the
perfectly working program and make it nonfunctional.

-- 
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

"" <nomail@nomail> wrote:
> >  This is a problem with GCC, not POV-Ray.  I have faced it myself
> > (though when compiling the Zlib included in the POV-Ray distro) trying
> > to compile with gcc-3.3.4.  According to GCC bugzilla*, this internal
> > compiler error (aka ICE) seems to occur in the 3.3 series on the AMD64,
> > at least this 3.3.4 release.
> >
> >  OTOH, POV-Ray compiles fine with the GCC 3.4.x series.  Moreover
> > the later supports the k8/opteron compiler flags, which should result in
> > a faster POV-Ray binary (also the 3.3.x series usually produce slightly
> > slower code on other platforms).  I recommand you install GCC 3.4.1 (or
> > the newest 3.4.2) and try again compiling POV-Ray with it -- works for me.
> >
> >  - NC
> >
> > (*) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16874
>
> Hello and thank you for your reply,
>
> but I still have the same error with gcc 3.4x series,
> unpacked form fresh source code did not use the "old" one:
>
> povms.cpp: In function `int POVMSUtil_TempAlloc(void**, int)':
> povms.cpp:3830: error: unerkennbares insn:
> (insn:HI 82 81 64 2 0x2a9682e780 (set (reg:SI 58)
>         (plus:SI (mult:SI (reg:SI 58)
>                 (const_int 2 [0x2]))
>             (const_int -2 [0xfffffffffffffffe]))) -1 (insn_list 81 (nil))
>     (nil))
> povms.cpp:3830: internal compiler error: in extract_insn, at recog.c:2175
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> For Debian GNU/Linux specific bug reporting instructions, see
> <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>.
> make[3]: *** [povms.o] Fehler 1

> make[2]: *** [all-recursive] Fehler 1

> make[1]: *** [all-recursive] Fehler 1

> make: *** [all] Fehler 2
>
> /usr/src/povray-3.6.1$> gcc -v
> Lese Spezifikationen von /usr/lib/gcc/x86_64-linux/3.4.2/specs
> Konfiguriert mit: ../src/configure -v
> --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
> --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
> --enable-shared --with-system-zlib --enable-nls --without-included-gettext
> --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
> --enable-java-awt=gtk --disable-werror x86_64-linux
> Thread-Modell: posix
> gcc-Version 3.4.2 (Debian 3.4.2-2)
>
> Is it possible to send me your .deb package?

I think I may have found why that happens. I had the same bug trying to
compile povray-3.6.1 under Ubuntu with gcc-3.3. When I switched to gcc-3.4
I also got an error about the chosen architecture not supporting 64 bit
code. It looks like the configure script identifies the architecture as
686. I went through all the Makefiles and changed the -march=686 to
-march=k8, after which it compiled.

Post a reply to this message