 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
After a few years of not povving I started do some work again with it and I am
delighted to see that a multi-threaded version is in beta!!! Great work POV
team!!! Thanks.
I downloaded the source code last week and tried to compile it on a Solaris X64
machine and ran into a few problems:
*) I had to install the boost library from http://www.sunfreeware.com/ and set
the --with-boost-thread=boost_thread-gcc34-mt flag for ./configure.
*) The ./configure script didn't like the version of the libz I had installed.
It complained it couldn't figure out which version it was even though it was a
good one. I suspect that this is an autoconf/Solaris issue though. Not quite
sure what to do about it. Same problem for the libpng, libtiff and libjpeg.
*) ./configure failed the size int test; it turned out I had to set
LD_LIBRARY_PATH manually to the libboost path (/usr/local/lib).
*) My system only had gmake and no make installed and I had to fix the Makefile
manually in a few places to make sure it used gmake instead of make.
*) Due to the a formentioned libz problems I went for the options to compile it
with out libz (and libpng etc.) yet the code still expected it to be there.This
was the failure:
Undefined first referenced
symbol in file
uncompress ../source/base/libbase.a(povmscpp.o)
ld: fatal: Symbol referencing errors. No output written to povray
I worked around it by compiling the file manually with libz and that worked
fine.
*) It turned out that my system didn't have ar installed, once installed it
worked fine, but I only found out during the compile. ./configure didn't check
for the binutils (not really important, since I suspect it will be installed on
most systems).
In the end this was my ./configure command:
../configure COMPILED_BY="XXXXXX" --with-boost-thread=boost_thread-gcc34-mt
--without-zlib NON_REDISTRIBUTABLE_BUILD=yes --without-libpng --without-libjpeg
--without-libtiff
Once compiled it all worked multi-threaded on my dual CPU machine...
unfortunately not such luck on an 8-way (octacore/octocore???) machine :( a bit
more investigation needed.
Also, gcc generated quite a few warnings (casts if I remember correctly). If
anyone wants more information let me know and I can post it for you.
Thanks again POV team!!!
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ooh and just to mention it; I got a 32 bit executable:
$ file povray
povray: ELF 32-bit LSB executable 80386 Version 1 [CMOV FPU],
dynamically linked, stripped
Would it be worth for ./configure checking 32/64 bit OS and adjusting make files
accordingly?
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> *) My system only had gmake and no make installed and I had to fix the Makefile
> manually in a few places to make sure it used gmake instead of make.
It should actually use $(MAKE), so that it uses the correct one
automatically.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> *) The ./configure script didn't like the version of the libz I had installed.
> It complained it couldn't figure out which version it was even though it was a
> good one. I suspect that this is an autoconf/Solaris issue though. Not quite
> sure what to do about it. Same problem for the libpng, libtiff and libjpeg.
>
> *) ./configure failed the size int test; it turned out I had to set
> LD_LIBRARY_PATH manually to the libboost path (/usr/local/lib).
Please mail me the config.log file that configure generated.
> *) My system only had gmake and no make installed and I had to fix the Makefile
> manually in a few places to make sure it used gmake instead of make.
That's odd, there should be *no* explicit reference to make within
any Makefile. Can you tell where you had to apply those changes?
> uncompress ../source/base/libbase.a(povmscpp.o)
> ld: fatal: Symbol referencing errors. No output written to povray
Ah-ah, indeed this one needs to be wrapped too. Thanks!
> *) It turned out that my system didn't have ar installed, once installed it
> worked fine, but I only found out during the compile. ./configure didn't check
> for the binutils (not really important, since I suspect it will be installed on
> most systems).
Thanks I will be adding an extra check.
> Also, gcc generated quite a few warnings
They are harmless.
Thanks again for reporting,
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas <tho### [at] gmx net> wrote:
> ooh and just to mention it; I got a 32 bit executable:
If I'm not completely mistaken, gcc 3.4 has no support for creating
64-bit Sparc executables. I don't know if gcc 4 has.
If it doesn't, the only way you can create a 64-bit Sparc executable
is by using Sun's own C++ compiler. However, unless they have brought it
up to date recently, it probably won't compile POV-Ray.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas <tho### [at] gmxnet> wrote:
> Once compiled it all worked multi-threaded on my dual CPU machine...
> unfortunately not such luck on an 8-way (octacore/octocore???) machine :( a bit
> more investigation needed.
What do you mean with that? It didn't compile? It didn't run? It crashed?
If what you mean is "even though there are 8 cores POV-Ray is still using
only 2" then the answer is that you have to give "-wt8" as parameter to
POV-Ray.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:47cae3aa@news.povray.org:
> Thomas <tho### [at] gmxnet> wrote:
>> ooh and just to mention it; I got a 32 bit executable:
>
> If I'm not completely mistaken, gcc 3.4 has no support for creating
> 64-bit Sparc executables. I don't know if gcc 4 has.
This is Solaris X64 and thus uses Intel x86-64 or Opteron chips not Sparc.
Turns out that gcc-3.4.3 was installed on the box and that can produce 64
bit code apparently, but haven't tried that yet.
> If it doesn't, the only way you can create a 64-bit Sparc executable
> is by using Sun's own C++ compiler. However, unless they have brought it
> up to date recently, it probably won't compile POV-Ray.
We have the Sun compiler (for x86) here, but I haven't tried it.,, and not
sure if I will have time to do so.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:47cae415@news.povray.org:
> Thomas <tho### [at] gmxnet> wrote:
>> Once compiled it all worked multi-threaded on my dual CPU machine...
>> unfortunately not such luck on an 8-way (octacore/octocore???)
>> machine :( a bit more investigation needed.
>
> What do you mean with that? It didn't compile? It didn't run? It
> crashed?
>
> If what you mean is "even though there are 8 cores POV-Ray is still
> using
> only 2" then the answer is that you have to give "-wt8" as parameter
> to POV-Ray.
>
The machine in question doesn't have the Boost libraries installed and just
copying the multi-thread bit and pointing LD_LIBRARY_PATH to it didn't fix
the problem. The program terminated directly failing to locate the library.
So I think I can fix this by installing the library unfortunatly I can't do
that on the 8 way machines :(
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] freefr> wrote in
news:47cadc64@news.povray.org:
>> *) The ./configure script didn't like the version of the libz I had
>> installed. It complained it couldn't figure out which version it was
>> even though it was a good one. I suspect that this is an
>> autoconf/Solaris issue though. Not quite sure what to do about it.
>> Same problem for the libpng, libtiff and libjpeg.
>>
>> *) ./configure failed the size int test; it turned out I had to set
>> LD_LIBRARY_PATH manually to the libboost path (/usr/local/lib).
>
> Please mail me the config.log file that configure generated.
DOH User error... Looking at the config.log it turned out the libz etc
test needed the LD_LIBRARY_PATH set as well. All ok now.
>> *) My system only had gmake and no make installed and I had to fix
>> the Makefile manually in a few places to make sure it used gmake
>> instead of make.
>
> That's odd, there should be *no* explicit reference to make
> within
> any Makefile. Can you tell where you had to apply those changes?
In the Makefile in the main directory and in the source and unix
directory are these lines:
MAKE=make
...
SET_MAKE = MAKE=make
I changed them to MAKE=gmake and then it all worked fine.
>> uncompress
>> ../source/base/libbase.a(povmscpp.o) ld: fatal: Symbol referencing
>> errors. No output written to povray
>
> Ah-ah, indeed this one needs to be wrapped too. Thanks!
no problem... I was probably the first to compile it that way
(understandably).
>> *) It turned out that my system didn't have ar installed, once
>> installed it worked fine, but I only found out during the compile.
>> ./configure didn't check for the binutils (not really important,
>> since I suspect it will be installed on most systems).
>
> Thanks I will be adding an extra check.
>
>> Also, gcc generated quite a few warnings
>
> They are harmless.
>
> Thanks again for reporting,
> - NC
Thanks,
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas van der Veen <tho### [at] gmxnet> wrote:
> > If I'm not completely mistaken, gcc 3.4 has no support for creating
> > 64-bit Sparc executables. I don't know if gcc 4 has.
> This is Solaris X64 and thus uses Intel x86-64 or Opteron chips not Sparc.
> Turns out that gcc-3.4.3 was installed on the box and that can produce 64
> bit code apparently, but haven't tried that yet.
I see. I suppose then it's just a question of whether gcc can create
the 64-bit executables in a format compatible with Solaris. I assume it can.
I suppose that the configure script could somehow detect that the system
is an x86-64 running Solaris and test if 64-bit binaries can be compiled.
Of course there should still be an option to compile a 32-bit binary
anyways, if the user wants one.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
