 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If you don't know the reason for the compile error you get it is quite
> unreasonable to assume this could be a bug in POV-Ray. If such an
> error was caused by a problem in the POV-Ray source how do you imagine
> that the official POV-Ray binaries could have been built at all?
Yes, we all know that if a piece of software compiles on one Unix-like
platform it is guaranteed to compile on all Unix-like platforms.
Or maybe not. Maybe if you compile software quite often, and it usually
works, and PoV doesn't, it is reasonable to go and ask the PoV-team what
is different that makes it break. Maybe it is a fault with a compilation
tool, or maybe a bug in PoV itself, or maybe just an out-of-date version
of something, but even if it's not a bug in PoV it's still worth
reporting it if only so other people with the same problem can find out
about it.
And Tim, if it's any consolation, it isn't at all obvious to me either.
Daniel
--
Misinformation followed us like a plague You can beat us with wires
Nobody knew from time to time You can beat us with chains
If the plans had changed You can run out your rules but you know
.: www.doublezero.uklinux.net :. You can't outrun the history train
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trf de> wrote:
> In article <web.40fea468a404e2e2300017f40@news.povray.org> , "Tim F"
> <fen### [at] stanfordedu> wrote:
>
> > This raises another question - why not leave the image library dependencies
> > external, and just not include them with the release?
>
> Because many people have extremely outdated versions and the start reporting
> problems in POV-Ray resulting from them having linked POV-Ray with outdated
> obsolete buggy libraries that had been fixed a long time ago.
But what happens when the problem is reversed? i.e. what if new libraries
appear that fix a bug or two in an external dependency to POVRay? Will new
point releases of POVRay be released, or should users download the new
libraries and rebuild POVRay, linking to the updated libraries?
I know its nit-picking, but I love playing devil's advocate. ;)
Regards,
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Daniel Hulme wrote:
>>If you don't know the reason for the compile error you get it is quite
>>unreasonable to assume this could be a bug in POV-Ray. If such an
>>error was caused by a problem in the POV-Ray source how do you imagine
>>that the official POV-Ray binaries could have been built at all?
>
>
> Yes, we all know that if a piece of software compiles on one Unix-like
> platform it is guaranteed to compile on all Unix-like platforms.
All this has nothing to do with POV-Ray and possible bugs, feel free to
ask for support with compiling POV-Ray in povray.unix but
povray.bugreports and the general groups are not the right place to
discuss this.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.40febe24a404e2e24e6ed3100@news.povray.org> , "Tim F"
<fen### [at] stanfordedu> wrote:
> But what happens when the problem is reversed? i.e. what if new libraries
> appear that fix a bug or two in an external dependency to POVRay? Will new
> point releases of POVRay be released, or should users download the new
> libraries and rebuild POVRay, linking to the updated libraries?
>
> I know its nit-picking, but I love playing devil's advocate. ;)
The configure & make automatically picks that version up for you, what else?
;-)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Tim F wrote:
> >
> > ? It is? I don't know the problem I'm seeing is only relevant to the *nix
> > version of the source (since I have no other platforms to test on), and my
> > impression was that this was the reasoning for the wording of the FAQ.
>
> If you don't know the reason for the compile error you get it is quite
> unreasonable to assume this could be a bug in POV-Ray.
I think I understand now - if I'm not positive its a bug in POVRay itself
(since it may be related to some oddball compiler problem, although the
error message and my fiddling suggests otherwise), post it to
povray.<insert OS here>? (I'm new to this newsgroup, if it isn't obvious)
FWIW, I should state that I've done many program builds and compiler/linker
tests in the past, and the fact that POVRay alone does not build strongly
suggests (IMHO) that the error lies in the POVRay source. Further, the
error message suggested a problem with the inclusion of several header
files with the same name (as Thorsten pointed out). Thus I did not
consider my assumption unreasonable at all.
> If such an error was caused by a problem in the POV-Ray source how do you
> imagine that the official POV-Ray binaries could have been built at all?
>
This is a rhetorical question - if there is an error in the POVRay source
such that the build fails, then its a bug. Period.
Regards,
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> In article <web.40febe24a404e2e24e6ed3100@news.povray.org> , "Tim F"
> <fen### [at] stanfordedu> wrote:
>
> > But what happens when the problem is reversed? i.e. what if new libraries
> > appear that fix a bug or two in an external dependency to POVRay? Will new
> > point releases of POVRay be released, or should users download the new
> > libraries and rebuild POVRay, linking to the updated libraries?
> >
> > I know its nit-picking, but I love playing devil's advocate. ;)
>
> The configure & make automatically picks that version up for you, what else?
> ;-)
>
(For some reason this got top posted on my first attempt - sorry about
that.)
But then you've missed the thrust of my argument - users that realize the
need to upgrade their libraries and rebuild povray won't have the same
problems as those that link against the libraries included with 3.6.
Therefore, users of the (now old) libraries will start submitting bug
reports - which goes back to your originally stated problem.
Again, its nit picking, but IMHO worth consideration.
Regards,
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim F" <fen### [at] stanfordedu> wrote in message
news:web.40fec787a404e2e24e6ed3100@news.povray.org...
> Christoph Hormann <chr### [at] gmxde> wrote:
> > Tim F wrote:
> povray.<insert OS here>? (I'm new to this newsgroup, if it isn't obvious)
welcome to the groups, Tim!
>
> This is a rhetorical question - if there is an error in the POVRay source
> such that the build fails, then its a bug. Period.
>
not really a bug. technically, a bug would be a programming error that
results in an incorrect rendering. this may be a misconfigured build system
or somethign to that effect (or may not be, i'll leave that discussion to
Thorsten and friends), but it's not a bug. if something in the POV source
makes a build fail, you can't really have a bug since there is no
executable. compile time errors are not really bugs.
anyway, i'm sure people will be more than helpfull in povray.unix. see you
there :)
-ross
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.40fec787a404e2e24e6ed3100@news.povray.org> , "Tim F"
<fen### [at] stanfordedu> wrote:
>> If such an error was caused by a problem in the POV-Ray source how do you
>> imagine that the official POV-Ray binaries could have been built at all?
>
> This is a rhetorical question - if there is an error in the POVRay source
> such that the build fails, then its a bug. Period.
There is no such problem because it simply is impossible that an identical
file can be different on any given system. However, the makefiles generated
for you, on the system you try to compile POV-Ray on, do change! Thus,
there is no question there is a problem building or using those makefiles to
suit your configuration. Still, even this does not say there is not simply
a bug in the tools on your system - on which configuration scripts for
POV-Ray depend to exist and run properly - that prevent a proper
configuration of your tools to compile POV-Ray. Either way, only after
Nicolas has been able to check the log files you hopefully sent him there
will be an answer if the configuration scripts are at fault or there is a
bug in your tools that the configuration scripts do need to work around.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim F" <fen### [at] stanfordedu> wrote in message
news:web.40feb772a404e2e24e6ed3100@news.povray.org...
> ? It is? I don't know the problem I'm seeing is only relevant to the *nix
> version of the source (since I have no other platforms to test on), and my
> impression was that this was the reasoning for the wording of the FAQ.
Sorry if you are confused. While povray.unix may be more appropriate, I can
understand how you ended up here.
-- Chris
POV-Team co-ordinator
Post a reply to this message
|
|
| |
| |
|
|
From: Nicolas Calimet
Subject: Re: povray 3.6 make error: problem solved
Date: 24 Jul 2004 07:35:45
Message: <41024991@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
