PovRay-3.50a (as of 2002-08-01)
gcc-3.1

Just like the message reported before, I also have compiling trouble,
but here as soon as the first .cpp file:


atmosph.cpp: In function `void do_rainbow(RAY*, INTERSECTION*, float*)':
atmosph.cpp:502: `max' undeclared (first use this function)
atmosph.cpp:502: (Each undeclared identifier is reported only once for each
    function it appears in.)
atmosph.cpp: In function `double constant_fog(RAY*, double, double, FOG*,
    float*)':
atmosph.cpp:688: `min' undeclared (first use this function)
make[1]: *** [atmosph.o] Error 1


I suspect many other problems  ;op


BTW, compilation obviously is made _without any_ optimization
(even no -O2 or -O3). It would be nice to add tests for compiler
flags into configure.in. I can provide a macro for that (which works
with the newer autoconf-2.53). If the binary distributed was compiled
in similar conditions, of course it will be MUCH SLOWER than anything
else (e.g. windows binary)

Thanx for releasing the sources anyway !!

- N.C.

Post a reply to this message

Nicolas Calimet wrote:

> PovRay-3.50a (as of 2002-08-01)
> gcc-3.1
> 
> Just like the message reported before, I also have compiling trouble,
> but here as soon as the first .cpp file:

It works with gcc-2.x. To get it compiled with 3.1 you need to add 
something like 

template<class T> const T& max(const T&a, const T&b)
{
return (a<b) ? b: a;
}

template<class T> const T& min(const T&a, const T&b)
{
return (a<b) ? a: b;
}

to an appropriate place. I chose frame.h.


> 
> BTW, compilation obviously is made _without any_ optimization
> (even no -O2 or -O3). 

I think the official binary had -O2 or -O3 because my first recompilation 
resulted slower.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

No, no! Don't kludge it. You can never know whether the STL implementations
are faster than that.
  The correct answer is to put 'using namespace std;' in config.h. (I don't
know why this hasn't be done already.)

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

>   No, no! Don't kludge it. You can never know whether the STL
>   implementations
> are faster than that.
>   The correct answer is to put 'using namespace std;' in config.h. (I
>   don't
> know why this hasn't be done already.)
> 

Yep, of course you are right. I just could not find a reference to min/max 
in STL in my documentation. To get it working it is already enough to add

using std::max;
using std::min;

into config.h. I even wondered why this wasn't in STL :D

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

Micha Riser inspired the electrons to say:

> Warp wrote:
> 
>>   No, no! Don't kludge it. You can never know whether the STL
>>   implementations
>> are faster than that.
>>   The correct answer is to put 'using namespace std;' in config.h. (I
>>   don't
>> know why this hasn't be done already.)
>> 

Oh no! No! please, don't....... Okay, importing the whole std namespace 
globally is ugly and was never recommented in any documentation I read, 
also I personally never do that too. I just import either locally or import 
explicitely.

> Yep, of course you are right. I just could not find a reference to min/max
> in STL in my documentation. To get it working it is already enough to add
> 
> using std::max;
> using std::min;

Exactly ;)

> into config.h. I even wondered why this wasn't in STL :D

Take a closer look.
I did it and found it in /usr/include/g++-v31/stl_algobase.h beginning at 
line 130. Look there, the Standard C directives min and max gets removed, 
and then replaced by its template functions and some specializations.

Cheers,
Christian Parpart.

p.s.: I also posted that in the .general feed. Hugh? I just looked here 
later ;)

Post a reply to this message

Christian Parpart <cpa### [at] surakwarenet> wrote:
> Oh no! No! please, don't....... Okay, importing the whole std namespace 
> globally is ugly and was never recommented in any documentation I read, 
> also I personally never do that too. I just import either locally or import 
> explicitely.

  I know all this (haven't you read my whinings in povray.off-topic about
the issue?-) ).
  Of course the most correct way of using it would be std::min and
std::max. However, I only suggested a quick fix which requires a minimum
amount of modification of the source code without modifying the result
in any way.
  Since POV-Ray is not well-structured C++, it doesn't really matter if
you dump everything to global visibility... :)

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

Micha Riser wrote:

> Yep, of course you are right. I just could not find a reference to min/max 
> in STL in my documentation. To get it working it is already enough to add
> 
> using std::max;
> using std::min;
> 
> into config.h. I even wondered why this wasn't in STL :D
> 
> - Micha
> 

Is there any special place in config.h that those two lines go?
I don't understand the structure of the file's contents and could
use a few pointers on this :)

Thanks

Post a reply to this message

Mr Art inspired the electrons to say:

> Micha Riser wrote:
> 
>> Yep, of course you are right. I just could not find a reference to
>> min/max in STL in my documentation. To get it working it is already
>> enough to add
>> 
>> using std::max;
>> using std::min;
>> 
>> into config.h. I even wondered why this wasn't in STL :D
>> 
>> - Micha
>> 
> 
> Is there any special place in config.h that those two lines go?
> I don't understand the structure of the file's contents and could
> use a few pointers on this :)

just put it below #include <algorithm>. That's okay ;)

Post a reply to this message

> Thanx for releasing the sources anyway !!
Yes thanks, too.

But I got an other problem here.
When compiling without any optimization (just ./configure, make)
I got:

g++  `if [ "Xgcc" = "Xgcc" ]; then echo "-Wno-multichar"; fi ` -static 
-I/usr/X11R6/include -o povray  atmosph.o bbox.o bcyl.o benchmark.o 
bezier.o blob.o boxes.o bsphere.o camera.o chi2.o colour.o colutils.o 
cones.o csg.o discs.o express.o file_pov.o fncode.o fnintern.o 
fnpovfpu.o fnsyntax.o fpmetric.o fractal.o function.o gif.o gifdecod.o 
hcmplx.o hfield.o histogra.o iff.o image.o interior.o isosurf.o 
jpeg_pov.o lathe.o lbuffer.o lightgrp.o lighting.o matrices.o media.o 
mesh.o normal.o objects.o octree.o optin.o optout.o parse.o parsestr.o 
parstxtr.o pattern.o pgm.o photons.o pigment.o planes.o png_pov.o 
point.o poly.o polygon.o polysolv.o pov_mem.o povms.o povmscpp.o 
povmsend.o povmsrec.o povray.o pov_util.o ppm.o prism.o quadrics.o 
quatern.o rad_data.o radiosit.o ray.o render.o renderio.o sor.o 
spheres.o sphsweep.o splines.o statspov.o super.o targa.o texture.o 
tiff_pov.o tokenize.o torus.o triangle.o truetype.o txttest.o userdisp.o 
userio.o vbuffer.o vlbuffer.o warps.o unix.o povxlib.o -L/usr/X11R6/lib 
-ltiff -ljpeg -lpng -lz -lm  -lX11
/usr/X11R6/lib/libX11.a(XlcDL.o): In function `try_both_dlsym':
XlcDL.o(.text+0x111): undefined reference to `dlsym'
XlcDL.o(.text+0x136): undefined reference to `dlsym'
/usr/X11R6/lib/libX11.a(XlcDL.o): In function `open_object':
XlcDL.o(.text+0x60e): undefined reference to `dlopen'
/usr/X11R6/lib/libX11.a(XlcDL.o): In function `close_object':
XlcDL.o(.text+0x684): undefined reference to `dlclose'
collect2: ld returned 1 exit status
make[1]: *** [povray] Fehler 1

Please don't kill me I'am no programmer but can anyone give me a hint?
(When using --without-x I get even more errors...)

Sebastian H.

Post a reply to this message

Open up src/Makefile and find this line:

LDFLAGS = -static -I/usr/X11R6/include
(could be a bit different but the LDFLAGS is the important line)

change it to:

LDFLAGS = -static -I/usr/X11R6/include -ldl
(note: added -ldl)

Try that and see if it works.

--josh

"Sebastian H." <seb### [at] webde> wrote in message
news:3D4### [at] webde...
> > Thanx for releasing the sources anyway !!
> Yes thanks, too.
>
> But I got an other problem here.
> When compiling without any optimization (just ./configure, make)
> I got:
>
> g++  `if [ "Xgcc" = "Xgcc" ]; then echo "-Wno-multichar"; fi ` -static
> -I/usr/X11R6/include -o povray  atmosph.o bbox.o bcyl.o benchmark.o
> bezier.o blob.o boxes.o bsphere.o camera.o chi2.o colour.o colutils.o
> cones.o csg.o discs.o express.o file_pov.o fncode.o fnintern.o
> fnpovfpu.o fnsyntax.o fpmetric.o fractal.o function.o gif.o gifdecod.o
> hcmplx.o hfield.o histogra.o iff.o image.o interior.o isosurf.o
> jpeg_pov.o lathe.o lbuffer.o lightgrp.o lighting.o matrices.o media.o
> mesh.o normal.o objects.o octree.o optin.o optout.o parse.o parsestr.o
> parstxtr.o pattern.o pgm.o photons.o pigment.o planes.o png_pov.o
> point.o poly.o polygon.o polysolv.o pov_mem.o povms.o povmscpp.o
> povmsend.o povmsrec.o povray.o pov_util.o ppm.o prism.o quadrics.o
> quatern.o rad_data.o radiosit.o ray.o render.o renderio.o sor.o
> spheres.o sphsweep.o splines.o statspov.o super.o targa.o texture.o
> tiff_pov.o tokenize.o torus.o triangle.o truetype.o txttest.o userdisp.o
> userio.o vbuffer.o vlbuffer.o warps.o unix.o povxlib.o -L/usr/X11R6/lib
> -ltiff -ljpeg -lpng -lz -lm  -lX11
> /usr/X11R6/lib/libX11.a(XlcDL.o): In function `try_both_dlsym':
> XlcDL.o(.text+0x111): undefined reference to `dlsym'
> XlcDL.o(.text+0x136): undefined reference to `dlsym'
> /usr/X11R6/lib/libX11.a(XlcDL.o): In function `open_object':
> XlcDL.o(.text+0x60e): undefined reference to `dlopen'
> /usr/X11R6/lib/libX11.a(XlcDL.o): In function `close_object':
> XlcDL.o(.text+0x684): undefined reference to `dlclose'
> collect2: ld returned 1 exit status
> make[1]: *** [povray] Fehler 1
>
> Please don't kill me I'am no programmer but can anyone give me a hint?
> (When using --without-x I get even more errors...)
>
> Sebastian H.
>
>
>

Post a reply to this message