As posted in p.g. i have now managed to compile POV-Ray 3.5 using the
Cygwin environment and the '-mno-cygwin' flag for creating a version that
does not depend on the cygwin emulation dll (equivalent to a MinGW
version).

Previous attempts resulted in an executable crashing at every start.  As
it seems the reason is the 'canonicalize_path()' function in unix.cpp. 
This function is used for the IO restrictions and does not seem to work
safely under all circumstances.  Deactivating the IO restrictions avoided
this problem but note that the existing 'IO_RESTRICTIONS_DISABLED' switch
does not work since it does not avoid calling 'canonicalize_path()' in
'UNIX_Allow_File_Write()'.

Another problem was the 'BLOB' type identifier that is also used in one of
the windows header files.  Adding some things to 'config.h' helped but
this required frame.h being the first included file in all modules. 
Another identifier collision was 'INT32' which is used in the jpeg library
and one of the windows files differently.  Is there an elegant method for
avoiding such problems in C++ BTW?

And finally something really strange: the compiler complained about the
'rad2' element of the blob struct.  Changing its name to 'rad_2' in
blob.cpp, blob.h and parse.cpp helped but i have no idea why.

If you want to compile POV-Ray with Cygwin/MinGW yourself you need the
Cygwin environment including the MinGW packages.  I don't know if the
plain MinGW works as well but there could be tools missing required by the
configure script etc.  Additionally you will need the support libraries
(zlib, libpng, libjpeg, libtiff) and comile them with the '-mno-cygwin'
flag.  When building POV-Ray you will also have to make sure the compiler
uses the MinGW versions of all header files and libraries.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> Is there an elegant method for avoiding such problems in C++ BTW?

  Namespaces were added to the language in order to help avoiding this
kind of problems.
  Of course it needs that those type declarations are made inside the
namespace when they are defined. I don't think you can "move" a definition
inside a namespace once it has been defined globally.

  Anyways, this is the main reason why all the C++ standard libraries and
definitions are inside the std namespace instead of being defined globally
(as is the case in C).

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

Christoph Hormann wrote:
> As posted in p.g. i have now managed to compile POV-Ray 3.5 using the
> Cygwin environment and the '-mno-cygwin' flag for creating a version that
> does not depend on the cygwin emulation dll (equivalent to a MinGW
> version).

Have you finally tried this compilation becouse of me ? ;-)

> Another problem was the 'BLOB' type identifier that is also used in one of
> the windows header files.  Adding some things to 'config.h' helped but
> this required frame.h being the first included file in all modules.

I have solved this other way. I have added switch to patches.h include
#define AVOID_NAME_COLLISION_PATCH
and I will catch there all possible collisions with different compilators.
Then I used in sources when needed
#ifdef AVOID_NAME_COLLISION_PATCH
  POV_BLOB
#else
  BLOB
#endif

> And finally something really strange: the compiler complained about the
> 'rad2' element of the blob struct.  Changing its name to 'rad_2' in
> blob.cpp, blob.h and parse.cpp helped but i have no idea why.

I have changed it the same way. This is the same case as BLOB collision.
'rad2' is constant in one of MinGW files. Check MinGW includes for it.

> If you want to compile POV-Ray with Cygwin/MinGW yourself you need the
> Cygwin environment including the MinGW packages.  I don't know if the
> plain MinGW works as well but there could be tools missing required by the
> configure script etc.

For example there is no make included in latest MinGW 2.0 packages. Some
strange ommision reported on MinGW website.

ABX

Post a reply to this message

"W?odzimierz ABX Skiba" wrote:
> 
> Have you finally tried this compilation becouse of me ? ;-)

Well i tried it before and when i looked after you told about your plans i
saw that gcc 3.2 is now available and i had a more detailed look.

> 
> > Another problem was the 'BLOB' type identifier that is also used in one of
> > the windows header files.  Adding some things to 'config.h' helped but
> > this required frame.h being the first included file in all modules.
> 
> I have solved this other way. I have added switch to patches.h include
> #define AVOID_NAME_COLLISION_PATCH
> and I will catch there all possible collisions with different compilators.
> Then I used in sources when needed
> #ifdef AVOID_NAME_COLLISION_PATCH
>   POV_BLOB
> #else
>   BLOB
> #endif

I'm not sure this is a good idea.  The 'BLOB' type occurs at quite a lot
of places and this would lead to a lot of modifications.  In general i
think it would be best to have no more modifications than necessary.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Włodzimierz ABX Skiba <abx### [at] abxartpl> wrote:
> #define AVOID_NAME_COLLISION_PATCH
> and I will catch there all possible collisions with different compilators.
> Then I used in sources when needed
> #ifdef AVOID_NAME_COLLISION_PATCH
>   POV_BLOB
> #else
>   BLOB
> #endif

  Wouldn't it just be easier to add a singe line (to config.h or wherever):

#define BLOB POV_BLOB

  Nothing else is needed. The preprocessor will change all instances
of the identifier 'BLOB' to 'POV_BLOB' before giving the source to the
compiler.

  (Of course that #define must be placed *after* the windows-specific
#includes which might define 'BLOB' in their own way.)

-- 
#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:
> 
> [...]
> #define BLOB POV_BLOB
> 
>   Nothing else is needed. The preprocessor will change all instances
> of the identifier 'BLOB' to 'POV_BLOB' before giving the source to the
> compiler.
> 
>   (Of course that #define must be placed *after* the windows-specific
> #includes which might define 'BLOB' in their own way.)

Interesting idea but sadly the povray source files are inconsistent about
order of the #include's for project specific and general files - placing
this in frame.h would not work.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3DC5527C.998E9103@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Interesting idea but sadly the povray source files are inconsistent about
> order of the #include's for project specific and general files - placing
> this in frame.h would not work.

Yes, it would.  frame.h will always be the first POV-Ray include file
included.

Anyway, maybe instead of chaging POV-Ray, how about simply not including the
Windows header files?  At least the one that is causing the problems.  After
all, they are obviously not needed to compile the Unix version....

    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:
> 
> > Interesting idea but sadly the povray source files are inconsistent about
> > order of the #include's for project specific and general files - placing
> > this in frame.h would not work.
> 
> Yes, it would.  frame.h will always be the first POV-Ray include file
> included.

frame.h is the first of the POV-Ray include files but the standard include
files are sometimes before, sometimes after them.

> Anyway, maybe instead of chaging POV-Ray, how about simply not including the
> Windows header files?  At least the one that is causing the problems.  After
> all, they are obviously not needed to compile the Unix version....
> 

In file included from /usr/include/w32api/windows.h:97,
                 from
/usr/include/c++/3.2/i686-pc-mingw32/bits/gthr-default.h:462,
                 from /usr/include/c++/3.2/i686-pc-mingw32/bits/gthr.h:98,
                 from
/usr/include/c++/3.2/i686-pc-mingw32/bits/c++io.h:37,
                 from /usr/include/c++/3.2/bits/fpos.h:44,
                 from /usr/include/c++/3.2/iosfwd:46,
                 from /usr/include/c++/3.2/bits/stl_algobase.h:70,
                 from /usr/include/c++/3.2/algorithm:66,
                 from config.h:64,
                 from frame.h:58,
                 from blob.cpp:94:
/usr/include/w32api/winsock2.h:27: ...

So unless i want to modify the standard header files...

In this case Warp's suggestion would help but some files (like
'fnpovfpu.cpp') have '#include <algorithm>' before '#include "frame.h"'

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3DC56FF9.C8C8BCA5@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> rame.h is the first of the POV-Ray include files but the standard include
> files are sometimes before, sometimes after them.

Yes, so what is the problem?  No modifications needed!  If you cannot just
keep the windows header files out (what are they doing in a Unix project in
the first place???), all you want it to adjust config.h properly!

So near the top of config.h add the offending file.  You suggested it seems
to be windows.h in your case.

So now you can be sure the "wrong" BLOB is always defined and included and
used prior to the "correct" BLOB being defined.  The next step is to add
what Warp suggested after the "wrong" BLOB has been defined.

Now compile.  If it still fails, continue adding the Windows specific header
files or whatever other files cause problem to config.h as outlined above.
This solution will work because all proper header files are protected from
double-inclusion.

Of course, the better solution would be to eliminate the inclusion of
windows.h, but if you are not sure how to do that without breaking anything
or where it is coming from, then the above will work as expected, only
compile a bit slower at worst.

    Thorsten


BTW, did you notice that the Windows version compiles without this problem
and without modifications...?  You may want to check how it solves this
problem!  (I did not bother.)

____________________________________________________
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

On Sun, 03 Nov 2002 16:27:07 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> I'm not sure this is a good idea.  The 'BLOB' type occurs at quite a lot
> of places

Not so much. Only 4 files IIRC.

> and this would lead to a lot of modifications.  In general i
> think it would be best to have no more modifications than necessary.

I will check further propositions from this thread.

BTW: I have not checked MinGW with Cygwin. I'm using it separated. I can't
find any INT32 conflict there so perhaps it is becouse of CygWin ? Comparing
compilation of POV3.5 with DJGPP and MinGW on the same machine DJGPP
compilation process is twice faster (I use exactly the same settings becouse I
use one shared makefile for them). It is probably becouse of extended headers
with all those windows constants from w32api. I have not tested speed of
exacutables but I have seen your results in general.

I have found one problem with pure MinGW. There is some problem with length of
commandline. For example I have no problem with creating archive/library with 
  ar rcs libsrc $(LIST_OF_SRC_MEMBERS)
when DJGPP is used. But it fails when pure (no cygwin) MinGW is used. It is
used in the same shell as DJGPP but it truncates command line at some
possition. I had to move this command from general process to each object
processing (add each object 'manually' after compilation), ie:
  bbox.o:
    g++ $(CFLAGS) -c -o bbox.o bbox.cpp
    ar rcs libsrc.a bbox.o
The same problem is not only for 'ar'. It is connected with command line in
MinGW with all tools, for example when more longer include paths is added with
-I.

ABX

Post a reply to this message