This is a bug report:

POV-Ray 3.5 fails to compile on Alpha-Linux (RH72), and probably most other
64-bit platforms.

In file included from /usr/include/tiffio.h:33,
                 from tiff_pov.cpp:46:
/usr/include/tiff.h:64: conflicting types for `typedef int int32'
frame.h:52: previous declaration as `typedef long int int32'

tiffio.h says

#if defined(__s390x__) || defined(__ia64__) || defined(__alpha) ||
(defined(_MIPS_SZLONG) && _MIPS_SZLONG == 64)
typedef int int32;
typedef unsigned int uint32;    /* sizeof (uint32) must == 4 */
#else
typedef long int32;
typedef unsigned long uint32;   /* sizeof (uint32) must == 4 */
#endif

frame.h attempts this:
typedef signed long int32 ;


on a 64-bit machine (linux), a long is 64-bits and int is 32-bits
on a 32-bit machine (linux), a long is 32-bits and int is 32-bits

------------
Andrew Schultz

Post a reply to this message

similarly, line 367 of optin.cpp should be:

POV_ISTREAM *Opts_Locate_File(char *filename, u_int32 stype, char *buffer,
int err_flag, POVMSObjectPtr obj);

(use "u_int32" instead of "unsigned long").  With this and the definition of
u_int32 fixed, povray compiles and seems to run.  However, the code is full
of "long" and "unsigned long" that are probably intended to be int32 and
u_int32.

---------------
Andrew Schultz

Post a reply to this message

In article <web.3d5bc2de56d1c4c89ecef47b0@news.povray.org> , "Andrew 
Schultz" <ajs### [at] eosncsuedu> wrote:

> frame.h attempts this:
> typedef signed long int32 ;

Just remove what you find in frame.h

    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

In article <web.3d5bdaa2b1abd86b9ecef47b0@news.povray.org> , "Andrew 
Schultz" <ajs### [at] eosncsuedu> wrote:

> However, the code is full
> of "long" and "unsigned long" that are probably intended to be int32 and
> u_int32.

Just confugure your compiler to make long 32 bit.  Most 64 bit platform
compilers support that.

    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 wrote:
>Just confugure your compiler to make long 32 bit.  Most 64 bit platform
>compilers support that.

That is a hack has the potential to busticate external include files that
use "long" properly.

The real solution is to not assume to know what the compiler thinks a long
is.  The framework to do so is there, it's just not always used.

-----------------
Andrew Schultz

Post a reply to this message

In article <web.3d5bf4e2b1abd86b9ecef47b0@news.povray.org> , "Andrew 
Schultz" <ajs### [at] eosncsuedu> wrote:

> That is a hack has the potential to busticate external include files that
> use "long" properly.

But there are no such files if you use a compiler switch!

> The real solution is to not assume to know what the compiler thinks a long
> is.  The framework to do so is there, it's just not always used.

Oh really? ;-)  I never said there is no "real" solution.  But who is going
to implement the "real" solution considering the size of the POV-Ray source
code...? :-(

    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 wrote:
>In article <web.3d5bf4e2b1abd86b9ecef47b0[at]news.povray.org> , "Andrew
>Schultz" <ajs### [at] eosncsuedu> wrote:
>
>> That is a hack has the potential to busticate external include files that
>> use "long" properly.
>
>But there are no such files if you use a compiler switch!

Are you saying that it won't include stdio.h if you use the compiler option?
If you compile with such an option and call fseek (which takes a long),
the compiler option would have it pass a 32-bit "long".  Wouldn't this (and
other situations throughout the code) cause major problems?

Additionally, gcc support for such an option is sparse and, for Alpha,
non-existent.

--------------
Andrew Schultz

Post a reply to this message

"Andrew Schultz" <ajs### [at] eosncsuedu> schrieb im Newsbeitrag
news:web.3d5c10e9b1abd86b9ecef47b0@news.povray.org...
> Are you saying that it won't include stdio.h if you use the compiler
option?
> If you compile with such an option and call fseek (which takes a long),
> the compiler option would have it pass a 32-bit "long".  Wouldn't this
(and
> other situations throughout the code) cause major problems?

Nope, it of course assume you link to the appropriate runtime libraries that
implement those calls in 32 bit.  Of course, this first of all assumes those
functions don't take arguments of a more abstract type (such as size_t)
already and those types are defined properly using compiler specific means.

> Additionally, gcc support for such an option is sparse and, for Alpha,
> non-existent.

Yes, on some platforms that habe been 64 bit "for a long time" it tends to
be not well supported anymore.  Other plaforms that had a vital 32 bit
predecessor such as Sparc at least did support it (haven't checked for years
though).

    Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Yes, on some platforms that habe been 64 bit "for a long time" it tends to
> be not well supported anymore.  Other plaforms that had a vital 32 bit
> predecessor such as Sparc at least did support it (haven't checked for years
> though).

  The UltraSparc processor can run processes in 32-bit or 64-bit mode
(in a similar way as Intel processors can run processes in 32-bit or 16-bit
mode). By default programs are compiled as 32-bit binaries by the Sun cc,
but can be compiled as 64-bit binaries with an architecture option. Gcc
can only compile 32-bit binaries.

  For some reason many people think that compiling a program as a 64-bit
binary would make it faster. That's not so, naturally. In fact, compiling
a program as 64-bit binary makes it slightly slower (this is most probably
because pointers and long integers are now 64 bits long instead of 32 bits,
and caches fill up faster). However, we are talking about only some percents
of slowdown.
  Even if the program uses the long long type (which is 64 bits regardless
of the compilation mode), compiling to a 64-bit binary makes it slightly
slower. Curiously gcc is really sloppy when optimizing long longs for Sparc.
A program which uses long longs a lot can be several times faster when
compiled with Sun cc than when compiled with gcc.

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

On Thu, 15 Aug 2002 22:16:05 +0200, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>Oh really? ;-)  I never said there is no "real" solution.  But who is going
>to implement the "real" solution considering the size of the POV-Ray source
>code...? :-(

Someone with a lot of time on their hands ?? Technically it's not a
difficult task, just a tedious one. Since I work for a company that
has 64-bit machines (so I can test it) I'm qualified, the problem is
the time. Ok, I also have to check if we have the right compiler for
my usual platform, IBM Z-series mainframes, I know we're at the right
OS level to have 64-bit support, I belive we have at least the
run-time libs, but it's no good without the right compiler. 

Any specific reason the change couldn't be done with a couple of
search & replaces pr source file ?? Back around POV-Ray 1.0 I actually
wrote some C parsing programs to facilitate a port to a mainframe, at
that time I had to mess with all the global names (functions and
variables) since the linker only supported 8 character external names.
Hmm, have to check if that limitation still exists as well.

/Erkki

Post a reply to this message