POV-Ray : Newsgroups : povray.unix : linking problems with POV-Ray 3.50c and Solaris Server Time
26 Dec 2024 14:55:04 EST (-0500)
  linking problems with POV-Ray 3.50c and Solaris (Message 1 to 4 of 4)  
From: Dennis Clarke
Subject: linking problems with POV-Ray 3.50c and Solaris
Date: 4 Apr 2003 04:02:30
Message: <Pine.GSO.4.53.0304040400240.5294@blastwave>
I think that the fol is a messy situation :

Undefined                       first referenced
 symbol                             in file
__1c2k6Fpv_v_                       file_pov.o
__1cG__CrunKpure_error6F_v_         jpeg_pov.o
__1cG__CrunMex_rethrow_q6F_v_       file_pov.o
__1cG__CrunIex_alloc6FI_pv_         povmscpp.o
__1c2n6FI_pv_                       file_pov.o
__1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_ povmscpp.o
ld: fatal: Symbol referencing errors. No output written to povray

Every object file is optimized for 32bit SPARC V8plus UltraSparc with no Linux
or Intel components in the fray.  Just some linking problems ...

can anyone recognize these ?

Dennis


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: linking problems with POV-Ray 3.50c and Solaris
Date: 4 Apr 2003 13:30:45
Message: <3e8dcf55@news.povray.org>
In article <Pine.GSO.4.53.0304040400240.5294@blastwave> , Dennis Clarke 
<dcl### [at] blastwaveorg>  wrote:

> ld: fatal: Symbol referencing errors. No output written to povray
>
> Every object file is optimized for 32bit SPARC V8plus UltraSparc with no Linux
> or Intel components in the fray.  Just some linking problems ...

Looks like you are missing the C++ runtime library or something like 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

From: Dennis Clarke
Subject: Re: linking problems with POV-Ray 3.50c and Solaris
Date: 15 Apr 2003 01:59:34
Message: <Pine.GSO.4.53.0304150156320.20603@blastwave>
On Fri, 4 Apr 2003, Thorsten Froehlich wrote:
>In article <Pine.GSO.4.53.0304040400240.5294@blastwave> , Dennis Clarke
><dcl### [at] blastwaveorg>  wrote:
>
>> ld: fatal: Symbol referencing errors. No output written to povray
>>
>> Every object file is optimized for 32bit SPARC V8plus UltraSparc with no Linux
>> or Intel components in the fray.  Just some linking problems ...
>
>Looks like you are missing the C++ runtime library or something like that.
>
>    Thorsten

 Actually things are moving along neatly now.  I have the build process down
 to a very deterministic procedure and am messing with compiler options to
 create a 64-bit binary.  I expect that the binary will be for the UltraSparc
 and it will be 64-bit.  I have no idea how well it will perform.  I expect
 that www.blastwave.org will have a package with multiple architecture revs
 ready to go .. real soon now.

 Dennis Clarke
 dcl### [at] blastwaveorg

 www.blastwave.org -- the home of community software for Solaris Sparc & Intel


Post a reply to this message

From: Warp
Subject: Re: linking problems with POV-Ray 3.50c and Solaris
Date: 15 Apr 2003 11:15:47
Message: <3e9c2223@news.povray.org>
Dennis Clarke <dcl### [at] blastwaveorg> wrote:
>  Actually things are moving along neatly now.  I have the build process down
>  to a very deterministic procedure and am messing with compiler options to
>  create a 64-bit binary.  I expect that the binary will be for the UltraSparc
>  and it will be 64-bit.  I have no idea how well it will perform.  I expect
>  that www.blastwave.org will have a package with multiple architecture revs
>  ready to go .. real soon now.

  The 64-bit compile will be some percents slower than a 32-bit compile
(supposing both are made with Sun's CC compiler).

  The reason is simple: Pointers are twice as long and thus caches are filled
some percents faster, which directly causes the program to be some percents
slower.
  There's nothing magical about a 64-bit binary over a 32-bit binary
speedwise. As execution speed is concerned, they are practically equivalent
(only the filling of caches is what makes the difference).

  The real reason for using 64-bit binaries instead of 32-bit ones is that
with the former you can address more than 4 gigabytes of memory at a time,
as well as handle files larger than 4 gigabytes (in some cases there might
be some use for the 64-bit 'long' type).
  POV-Ray probably will not have any use for these features (ok, you might
make a scene which requires more than 4 gigabytes of memory, but that's
unlikely even if you *have* that much memory in your computer), so it's
mostly useless making a 64-bit compile which is some percents slower.

  If anything, it might have some academical interest.

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

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