The build problem reported by Tim has been solved, and I'd like
to thank him for reporting it and for the tests he did at my request.
A workaround should be implemented in the future version of the build
system of POV-Ray for Unix.  This message is meant to serve as reference
in the mean time.


	Short version:

The problem is _not_ due to the build system in POV-Ray for Unix
per se, but rather to the combination of:
- a particular setting in one environment variable
- a (seemingly) buggy behavior of the compiler used -- here gcc,
   possibly affecting all versions.

The build failure is due to having the environment variable
C_INCLUDE_PATH set with a "." (current directory) in the list of
include paths, and gcc wrongly removing all duplicate "." entries.

Workaround: do not set C_INCLUDE_PATH (or any similar environment
variable used by the compiler) with the "." path.  An (untested)
alternative is to build POV-Ray in a different directory than in
its source tree; see section 4.1.3 of the INSTALL file.


	Long version:

Facts:

1) The build failure in the unix/ directory is the consequence of
    unix/config.h not being read; the definitions contained therein
    are thus missing and lead to compilation errors in other files.

2) Instead, a config.h file is read in another directory (here in
    the 3rd-party zlib library in ../libraries/zlib).  Using this
    config.h file generates the warnings that appear before the
    make errors.

Causes:

1) The C_INCLUDE_PATH environment variable is set for the user
    (e.g. in his $HOME/.bash_profile configuration file) with
    something like
      C_INCLUDE_PATH=.:/home/user/include
    where the first dot means the current directory.  These paths
    are normally used by the compiler to search for header files
    included in C sources.

2) For compiling POV-Ray, several include paths are specified on
    the compiler command-line using -Ipath flags.  These flags are
    normally prepended to the list of paths used to search for
    include files.  The compiler then searches for include files
    in the following order:
      1) all -Ipath specified at the command-line, in the given order;
      2) paths specified through environment variables specified by
         the user, in the given order;
      3) default (system) search paths (unless the compiler is asked
         not to search in system paths), in a system-specific order.
    The -I. compiler flag is usually used when compiling each
    source file.

3) For some unknown reason, the gcc (g++) compiler does the following
    when compiling a C++ source file:

    (tested in the unix/ directory using the -v compiler option,
simplified output)

g++ -I. -I. -I..  -I.. -I../source -I../source/base -I../source/frontend
     -I../source -I../libraries/zlib -I../libraries/png -I../libraries/tiff/libtiff
     -I../libraries/tiff/libtiff  -I/usr/X11R6/include  -v -c -o svga.o
    `test -f 'svga.cpp' || echo './'`svga.cpp
<snip>
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
ignoring duplicate directory "."
   as it is a non-system directory that duplicates a system directory
ignoring duplicate directory "."
   as it is a non-system directory that duplicates a system directory
ignoring duplicate directory ".."
ignoring duplicate directory "../source"
ignoring duplicate directory "../libraries/tiff/libtiff"
#include "..." search starts here:
#include <...> search starts here:
  ..
  ../source
  ../source/base
  ../source/frontend
  ../libraries/zlib
  ../libraries/png
  ../libraries/tiff/libtiff
  /usr/X11R6/include
  .
  /home/user/include
  /usr/include/c++/3.2.2
  /usr/include/c++/3.2.2/i386-redhat-linux
  /usr/include/c++/3.2.2/backward
  /usr/local/include
  /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include
  /usr/include
End of search list.

	Note that gcc decides to completely remove the "." directory from
the search list of include files, while -I. was specified as the first
path to be searched (here twice: the second -I. is due to the fact that
the user builds POV-Ray directly in its source tree).
	Apparently gcc removes "." because it considers that the "." given
in C_INCLUDE_PATH (here right before /home/user/include) is a system directory.
Also in principle C_INCLUDE_PATH should be ignored when compiling a C++ source
(the preprocessor should use CPLUS_INCLUDE_PATH instead).
	As a result, the ./config.h file is not found for the C++ source file.
Instead the first config.h file found in the list above (in ../libraries/zlib
in this case) is used instead.  The "." found in the search list is too low
in the list to be useful here.  (On systems where compiling the 3rd-party
libraries is not required, the build could eventually succeed.)

Conclusion:

A possible workaround is to remove "." from the search list in C_INCLUDE_PATH.
Alternatively, one can build the POV-Ray source in another directory so as to
have gcc use a -Ipath refering to the unix/ directory by something else but
the "." path.


	- NC

Post a reply to this message

> The problem is _not_ due to the build system in POV-Ray for Unix
> per se, but rather to the combination of:
> - a particular setting in one environment variable
> - a (seemingly) buggy behavior of the compiler used -- here gcc,
>   possibly affecting all versions.

	The problem reported earlier was found with the following:

GNU C++ version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)  *


	On a quick test, these versions:

GNU C++ version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)  **
GNU G++ version 3.4.1                                   ***

	cause the same problem when CPLUS_INCLUDE_PATH contains a "."
(however, the C_INCLUDE_PATH environment variable has no effect here,
as expected).


	- NC

*   version shipped with Red Hat 9
**  version shipped with Red Hat Fedora Core 1
*** version compiled from sources

Post a reply to this message

Nicolas Calimet wrote:
>> The problem is _not_ due to the build system in POV-Ray for Unix
>> per se, but rather to the combination of:
>> - a particular setting in one environment variable
>> - a (seemingly) buggy behavior of the compiler used -- here gcc,
>>   possibly affecting all versions.
> 
I did not verify things myself but if you feel that this is a bug in gcc, 
did you feed a bug report into the GCC bugzilla?

Wolfgang

Post a reply to this message

> - a (seemingly) buggy behavior of the compiler used -- here gcc,
>   possibly affecting all versions.

	Okay, that is actually _not_ a GCC bug (but a documented feature)
to treat the *_INCLUDE_PATH paths as system paths.  According to the gcc
info file/man page:

`CPATH'
`C_INCLUDE_PATH'
`CPLUS_INCLUDE_PATH'
`OBJC_INCLUDE_PATH'

      <snip>
      `CPATH' specifies a list of directories to be searched as if
      specified with `-I', but after any paths given with `-I' options
      on the command line.  This environment variable is used regardless
      of which language is being preprocessed.

      The remaining environment variables apply only when preprocessing
      the particular language indicated.  Each specifies a list of
      directories to be searched as if specified with `-isystem', but
      after any paths given with `-isystem' options on the command line.
      <snip>

and:

`-isystem DIR'
      Search DIR for header files, after all directories specified by
      `-I' but before the standard system directories.  Mark it as a
      system directory, so that it gets the same special treatment as is
      applied to the standard system directories.


	So, setting e.g. CPLUS_INCLUDE_PATH with a "." is surely a
mistake that should be avoided at all costs.

	- NC

Post a reply to this message

In article <4103c65f$1@news.povray.org> , Nicolas Calimet 
<pov### [at] freefr>  wrote:

>  So, setting e.g. CPLUS_INCLUDE_PATH with a "." is surely a
> mistake that should be avoided at all costs.

Then it seems logical to check for this error in the configure script and
refuse to continue (referring to the gcc documentation) until that error is
fixed by the user.  Of course, this is assuming it cannot be fixed on the
fly (in which case a warning might still be a good idea, imho).

    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

> Then it seems logical to check for this error in the configure script and
> refuse to continue (referring to the gcc documentation) until that error is
> fixed by the user.

	This is what I had in mind  :-)
	More precisely, configure would be allowed to complete (as such a
mistake does not influence the configuration itself), but a prominently
warning would be issued at the end -- of course that would not prevent
users to "miss the message by chance" <sigh>

> Of course, this is assuming it cannot be fixed on the
> fly (in which case a warning might still be a good idea, imho).

	I think it can (at the Makefile.am level) but didn't try it yet.
Therefore the exact strategy to workaround this problem is to be set  :-)

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
>
>  So, setting e.g. CPLUS_INCLUDE_PATH with a "." is surely a
> mistake that should be avoided at all costs.
>

Thanks for setting me straight on this, and I guess I should explain how I
ended up breaking stuff, since I think its a common problem.  I have in my
..bash_profile:

export CPLUS_INCLUDE_PATH=${CPLUS_INCLUDE_PATH}:/dir/to/add:/another/one

which is done to prevent overwriting any formerly set CPLUS_INCLUDE_PATH,
but has the side effect of adding "." to CPLUS_INCLUDE_PATH if it *isn't*
set. I think many people do this, and perhaps without realizing how it
affects compiler behavior (like me).  I guess I could/should use something
like:

CPLUS_INCLUDE_PATH=${CPLUS_INCLUDE_PATH:+"$CPLUS_INCLUDE_PATH:"}/dir/to/add
export CPLUS_INCLUDE_PATH

but its a bit of hack.  Surprisingly, this is the first time it actually
borked up a compile attempt...

Regards,
Tim

Post a reply to this message

> export CPLUS_INCLUDE_PATH=${CPLUS_INCLUDE_PATH}:/dir/to/add:/another/one
> 
> which is done to prevent overwriting any formerly set CPLUS_INCLUDE_PATH,
> but has the side effect of adding "." to CPLUS_INCLUDE_PATH if it *isn't*
> set.

	Indeed.  This behaviour is also documented in the gcc man/info pages.

	Now the question is: why do you prepend $CPLUS_INCLUDE_PATH in the
first place ?  I'd expect to _append_ it to your own list of paths, thus
preventing this implicit "." to be added automatically:

export CPLUS_INCLUDE_PATH=/dir/to/add:/another/one:${CPLUS_INCLUDE_PATH}

	Doing so seems more logical (to me).
	For instance: your system contains a library that you want to
replace by a newer version you installed in /dir/to/add (assuming this
directory is in your user space, and is not rooted as written here).
Prepending the /dir/to/add path is the only way to let the compiler
"see" the newer version first.  Otherwise, appending this path to
those given in the former CPLUS_INCLUDE_PATH could simply have no
effect: maybe there is another, older version of this library in the
initial CPLUS_INCLUDE_PATH's.

> Surprisingly, this is the first time it actually
> borked up a compile attempt...

	Among other possibilities:
- The new build system is not mature yet, maybe there's some deep issue
   here that I overlooked;
- Not so many packages automatically configure & build the required
   independent third-party libraries;
- Not sure how many people use the *_INCLUDE_PATH in general (honestly
   I didn't know about it before you reported the problem)  ;-)

	Anyway, version 3.6.1 will have configure handle this situation
automatically (at least my tests seem to work).

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
>
>  Now the question is: why do you prepend $CPLUS_INCLUDE_PATH in the
> first place ?  I'd expect to _append_ it to your own list of paths, thus
> preventing this implicit "." to be added automatically:
>
> export CPLUS_INCLUDE_PATH=/dir/to/add:/another/one:${CPLUS_INCLUDE_PATH}
>

sure, but this still isn't a guaranteed win.  CPLUS_INCLUDE_PATH could be
modified further by some other program/script, and there's no way one can
be sure to be consistent/correct 100% of the time.  I guess thats why I
like using the bash:

${param:+word}

construct - it will check if param is set, at least, and do the Right Thing
if it isn't.

The struggle continues.  ;)

Regards,
Tim

Post a reply to this message