|
|
|
|
|
|
| |
| |
|
|
From: marabou
Subject: compile error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in this scope
Date: 15 Jul 2009 10:30:58
Message: <4a5de822@news.povray.org>
|
|
|
| |
| |
|
|
hello,
I just tried to compile povray-3.7.0.beta.32 as normal user and got an
compile error.
Does anybody have an idea what was getting wrong or what is missing?
The only hint I have found was at http://www.povray.org/beta/revision.txt.
Thank you in advance.
An extract of log:
> ./configure COMPILED_BY="your name <email@address>"
===============================================================================
Configure POV-Ray version 3.7.0.beta.32
===============================================================================
This is an unofficial version compiled by:
your name <email@address>
The POV-Ray Team(tm) is not responsible for supporting this version.
Environment
-----------
checking build system type... i386-unknown-freebsd7.2
checking host system type... i386-unknown-freebsd7.2
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... unix/config/install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether $C_INCLUDE_PATH contains the "." path... no
checking whether $CPLUS_INCLUDE_PATH contains the "." path... no
Programs
--------
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether the g++ compiler works... yes
checking how to run the C++ preprocessor... g++ -E
checking for C++ compiler vendor... gnu
checking for g++ version... 4.2.1
checking for ranlib... ranlib
Libraries
---------
checking whether to link with cygwin DLL... no
checking whether to enable static linking... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... -D_THREAD_SAFE
checking whether to build the boost thread library from sources... no
checking for boostlib >= 1.35... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the boost thread library is usable... yes
checking for sin in -lmkl... no
checking for sin in -lm... yes
checking for clock_gettime in -lrt... yes
checking whether to use the ZLIB library... yes
checking for library containing zlibVersion... -lz
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for libz version >= 1.2.1... 1.2.3, ok
checking whether to use the PNG library... yes
checking for library containing png_get_libpng_ver... -lpng
checking png.h usability... yes
checking png.h presence... yes
checking for png.h... yes
checking for libpng version >= 1.2.5... 1.2.34, ok
checking whether to use the JPEG library... yes
checking for library containing jpeg_std_error... -ljpeg
checking jpeglib.h usability... yes
checking jpeglib.h presence... yes
checking for jpeglib.h... yes
checking for libjpeg version >= 6b (62)... 62, ok
checking whether to use the TIFF library... yes
checking for library containing TIFFGetVersion... -ltiff
checking tiffio.h usability... yes
checking tiffio.h presence... yes
checking for tiffio.h... yes
checking for libtiff version >= 3.6.1... 3.8.2, ok
checking whether to use the OpenEXR library... yes
checking for pkg-config... pkg-config
checking for OpenEXR's pkg-config... yes
checking for OpenEXR version >= 1.2... 1.6.1, ok
checking OpenEXR/ImfCRgbaFile.h usability... yes
checking OpenEXR/ImfCRgbaFile.h presence... yes
checking for OpenEXR/ImfCRgbaFile.h... yes
checking for ImfInputReadPixels in -lIlmImf... yes
checking vga.h usability... yes
checking vga.h presence... yes
checking for vga.h... yes
checking for vga_init in -lvga... yes
checking vgagl.h usability... yes
checking vgagl.h presence... yes
checking for vgagl.h... yes
checking for gl_setcontextvga in -lvgagl... yes
checking for X... libraries /usr/lib, headers /usr/include
checking whether -R must be followed by a space... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking X11/Xlib.h usability... yes
checking X11/Xlib.h presence... yes
checking for X11/Xlib.h... yes
checking for XFlush in -lX11... yes
checking X11/xpm.h usability... yes
checking X11/xpm.h presence... yes
checking for X11/xpm.h... yes
checking for XpmCreatePixmapFromData in -lXpm... yes
checking whether to enable the watch cursor... no
checking for sdl-config... sdl-config
checking for libSDL... yes
checking for libSDL version >= 1.2... 1.2.13, ok
checking SDL/SDL.h usability... yes
checking SDL/SDL.h presence... yes
checking for SDL/SDL.h... yes
checking for SDL_Quit in -lSDL... yes
Language constructs and functions
---------------------------------
checking whether time.h and sys/time.h may both be included... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for size_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking size of int... 4
checking size of long int... 4
checking size of size_t... 4
checking size of float... 4
checking for working memcmp... yes
checking return type of signal handlers... void
checking for vsnprintf... yes
checking for getcwd... yes
checking for readlink... yes
checking for nanosleep... yes
checking for clock_gettime... yes
checking for getrusage... yes
checking for gettimeofday... yes
checking for asinh... yes
Compiling
---------
checking whether to enable pipes for communications... yes
checking whether g++ accepts -pipe... yes
checking whether g++ accepts -Wno-multichar... yes
checking whether g++ accepts -Wno-write-strings... yes
checking whether g++ accepts -fno-enforce-eh-specs... yes
checking whether to enable I/O restrictions... yes
checking whether to enable debugging... no
checking whether to enable profiling... no
checking whether to enable stripping... yes
checking whether g++ accepts -s... yes
checking whether to enable optimizations... yes
checking whether g++ accepts -O3... yes
checking whether g++ accepts -ffast-math... yes
checking whether to enable architecture-specific optimizations... yes
checking whether g++ accepts -malign-double... yes
checking whether g++ accepts -xHost... no
checking whether g++ accepts -march=native... yes
checking which architecture to optimize for... i386-unknown-freebsd7.2
(using -march=native)
Makefiles
---------
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libraries/Makefile
config.status: creating libraries/boost/Makefile
config.status: creating source/base/Makefile
config.status: creating source/backend/Makefile
config.status: creating source/frontend/Makefile
config.status: creating source/Makefile
config.status: creating vfe/Makefile
config.status: creating unix/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
===============================================================================
POV-Ray 3.7.0.beta.32 has been configured.
Built-in features:
I/O restrictions: enabled
X Window display: enabled (using SDL)
SVGAlib display: enabled
Supported image formats: gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -
Compilation settings:
Build architecture: i386-unknown-freebsd7.2
Built/Optimized for: i386-unknown-freebsd7.2 (using -march=native)
Compiler vendor: gnu
Compiler version: g++ 4.2.1
Compiler flags: -pipe -Wno-multichar -Wno-write-strings -fno-
enforce-eh-specs -s -O3 -ffast-math -malign-double -march=native -
D_THREAD_SAFE -pthread
Type 'make check' to build the program and run a test render.
Type 'make install' to install POV-Ray on your system.
The POV-Ray components will be installed in the following directories:
Program (executable): /usr/local/bin
System configuration files: /usr/local/etc/povray/3.7
User configuration files: /home/xxx/.povray/3.7
Standard include files: /usr/local/share/povray-3.7/include
Standard INI files: /usr/local/share/povray-3.7/ini
Standard demo scene files: /usr/local/share/povray-3.7/scenes
Documentation (text, HTML): /usr/local/share/doc/povray-3.7
Unix man page: /usr/local/share/man
===============================================================================
> time make check
Making check in libraries
Making check in source
Making check in backend
[..]
mv -f .deps/pov_mem.Tpo .deps/pov_mem.Po
rm -f libpovray.a
ar cru libpovray.a lightgrp.o optout.o pov_mem.o
ranlib libpovray.a
Making check in vfe
g++ -DHAVE_CONFIG_H -DPOVLIBDIR=\"/usr/local/share/povray-3.7\" -
DPOVCONFDIR=\"/usr/local/etc/povray/3.7\" -DPOVCONFDIR_BACKWARD=\"/usr/
local/etc\" -I. -I.. -I../vfe/unix -I../unix -I../source -I../source/
base -I../source/backend -I/usr/local/include/SDL -I/usr/local/include -
D_GNU_SOURCE=1 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/
OpenEXR -pthread -I/usr/local/include -I/usr/include -pipe -Wno-
multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -
malign-double -march=native -D_THREAD_SAFE -pthread -MT platformbase.o -
MD -MP -MF .deps/platformbase.Tpo -c -o platformbase.o `test -f 'unix/
platformbase.cpp' || echo './'`unix/platformbase.cpp
unix/platformbase.cpp: In member function 'long long unsigned int
pov_base::vfeTimer::GetCPUTime() const':
unix/platformbase.cpp:194: error: 'CLOCK_PROCESS_CPUTIME_ID' was not
declared in this scope
*** Error code 1
Stop in /usr/home/xxx/sources/povray-3.7.0.beta.32/vfe.
*** Error code 1
Stop in /usr/home/xxx/sources/povray-3.7.0.beta.32.
245.258u 14.590s 4:19.42 100.1% 7458+1738k 1+80io 0pf+0w
Post a reply to this message
|
|
| |
| |
|
|
From: Le Forgeron
Subject: Re: compile error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in thisscope
Date: 15 Jul 2009 11:51:55
Message: <4a5dfb1b$1@news.povray.org>
|
|
|
| |
| |
|
|
Le 15/07/2009 16:30, marabou nous fit lire :
[SNIP]
Notice to support: he is on freebsd, I'm afraid of some linuxism in the code.
7.2 is the actual production version (there is a 8.0 in beta)
Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd 7.2 and lower
for
not having it ? (no assertion about 8.0)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
marabou <not### [at] availableyet> wrote:
> I just tried to compile povray-3.7.0.beta.32 as normal user and got an
> compile error.
> Does anybody have an idea what was getting wrong or what is missing?
> The only hint I have found was at http://www.povray.org/beta/revision.txt.
> Thank you in advance.
From the details I gather that you are trying to compile on some Unix/Linux
machine; so if you should get no responses here, you may want to try asking in
povray.unix as well.
In any case, I guess some details about your platform (at least Linux distro &
version info) would be helpful. Due to frequent issues, I also expect people
will want to know the boost library version installed on your system.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] freefr> wrote:
> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd 7.2 and lower
for
> not having it ? (no assertion about 8.0)
Sounds like a reasonable option :P (SCNR)
I'd say it depends on how complicated it would be to fix. At any rate, it's
worth entering into the bugtracker as a compatibility issue. As you seem to be
into details to some degree, would you mind...? kthxbye ;)
Post a reply to this message
|
|
| |
| |
|
|
From: Darren New
Subject: Re: compile error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in this scop=
Date: 15 Jul 2009 18:33:26
Message: <4a5e5936@news.povray.org>
|
|
|
| |
| |
|
|
clipka wrote:
> From the details I gather that you are trying to compile on some Unix/Linux
> machine;
Did anyone else see Clippy floating in the air there while reading this?
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
From: Le Forgeron
Subject: Re: compile error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in thisscope
Date: 16 Jul 2009 04:11:54
Message: <4a5ee0ca$1@news.povray.org>
|
|
|
| |
| |
|
|
Le 15/07/2009 19:40, clipka nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd 7.2 and
lower for
>> not having it ? (no assertion about 8.0)
>
> Sounds like a reasonable option :P (SCNR)
>
> I'd say it depends on how complicated it would be to fix. At any rate, it's
> worth entering into the bugtracker as a compatibility issue. As you seem to be
> into details to some degree, would you mind...? kthxbye ;)
>
>
>
Entry add in bugtracker, as per request.
Post a reply to this message
|
|
| |
| |
|
|
From: marabou
Subject: Re: compile error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in thisscope
Date: 16 Jul 2009 14:23:19
Message: <4a5f7017$1@news.povray.org>
|
|
|
| |
| |
|
|
On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:
> Le 15/07/2009 19:40, clipka nous fit lire :
>> Le_Forgeron <jgr### [at] freefr> wrote:
>>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd
>>> 7.2 and lower for not having it ? (no assertion about 8.0)
>>
>> Sounds like a reasonable option :P (SCNR)
>>
>> I'd say it depends on how complicated it would be to fix. At any rate,
>> it's worth entering into the bugtracker as a compatibility issue. As
>> you seem to be into details to some degree, would you mind...? kthxbye
>> ;)
>>
>>
>>
> Entry add in bugtracker, as per request.
I thank you for it ;)
Post a reply to this message
|
|
| |
| |
|
|
From: marabou
Subject: Re: compile error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in thisscope
Date: 16 Jul 2009 15:33:38
Message: <4a5f8092@news.povray.org>
|
|
|
| |
| |
|
|
On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:
> Le 15/07/2009 19:40, clipka nous fit lire :
>> Le_Forgeron <jgr### [at] freefr> wrote:
>>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd
>>> 7.2 and lower for not having it ? (no assertion about 8.0)
>>
>> Sounds like a reasonable option :P (SCNR)
>>
>> I'd say it depends on how complicated it would be to fix. At any rate,
>> it's worth entering into the bugtracker as a compatibility issue. As
>> you seem to be into details to some degree, would you mind...? kthxbye
>> ;)
>>
>>
>>
> Entry add in bugtracker, as per request.
Povray does compile now. The patch follows. But there is another problem
which is ugly:
[..]
Making all in libraries
Making all in source
Making all in backend
Making all in base
Making all in frontend
Making all in vfe
Making all in unix
./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240
+a0.3 +L./include
povray: this pre-release version of POV-Ray for Unix has expired
*** Error code 1
Stop in /usr/home/user/sources/povray-3.7.0.beta.32.
How can I circumvent it?
Another question:
If Povray executes, how can I check if my patch is successful? Would
Povray start? Would it crash? Which checks have to be done?
Thank you in advance.
---------------------------------------------------------------
Patch:
--- vfe/unix/platformbase.cpp.old 2009-07-16 21:24:30.000000000 +0200
+++ vfe/unix/platformbase.cpp 2009-07-16 21:18:36.000000000 +0200
@@ -191,7 +191,11 @@ namespace pov_base
{
#ifdef HAVE_CLOCK_GETTIME
struct timespec ts;
+#if defined (__FreeBSD__)
+ if (clock_gettime(m_ThreadTimeOnly ? CLOCK_THREAD_CPUTIME_ID : CLOCK_REALTIME, &ts)
== 0)
+#else
if (clock_gettime(m_ThreadTimeOnly ? CLOCK_THREAD_CPUTIME_ID :
CLOCK_PROCESS_CPUTIME_ID, &ts) == 0)
+#endif
return (unsigned POV_LONG) (1000)*ts.tv_sec + ts.tv_nsec/1000000;
#endif
#ifdef HAVE_GETRUSAGE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
marabou <not### [at] availableyet> wrote:
> On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:
>
> > Le 15/07/2009 19:40, clipka nous fit lire :
> >> Le_Forgeron <jgr### [at] freefr> wrote:
> >>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd
> >>> 7.2 and lower for not having it ? (no assertion about 8.0)
> >>
> >> Sounds like a reasonable option :P (SCNR)
> >>
> >> I'd say it depends on how complicated it would be to fix. At any rate,
> >> it's worth entering into the bugtracker as a compatibility issue. As
> >> you seem to be into details to some degree, would you mind...? kthxbye
> >> ;)
> >>
> >>
> >>
> > Entry add in bugtracker, as per request.
>
> I thank you for it ;)
Looks like Le_Forgeron not only entered the issue, but already did a thorough
analysis; I can only agree with all his conclusions: It should be a matter of
../configure identifying that CLOCK_PROCESS_CPUTIME_ID isn't available, and in
that case not setting HAVE_CLOCK_GETTIME, but HAVE_GETRUSAGE instead; as the
code seems to be well prepared for dealing with clock_gettime() being
unavailable, issues worse than possibly misleading statistics are not to be
expected.
So no need to loathe freebsd for this :)
Post a reply to this message
|
|
| |
| |
|
|
From: marabou
Subject: Re: compile error: 'CLOCK_PROCESS_CPUTIME_ID' was not declared in thisscope
Date: 16 Jul 2009 16:16:11
Message: <4a5f8a8b$1@news.povray.org>
|
|
|
| |
| |
|
|
On Thu, 16 Jul 2009 16:06:28 -0400 clipka wrote:
> 3.0.4506.2152; .NET CLR 3.5.30729)
> NNTP-Posting-Host: 203.29.75.35
> X-Trace: news.povray.org 1247775001 203.29.75.35 (16 Jul 2009 16:10:01
> -0400) Lines: 33
> X-No-Archive: Yes
> X-Copyright: This copyrighted article comes from a private news server
> and may NOT be distributed on USENET or other news servers.
> X-POV-Header: --- --- --- --- --- --- --- --- --- --- --- --- Path:
> news.povray.org!81.173.238.87
> Xref: news.povray.org povray.beta-test:10235
>
> marabou <not### [at] availableyet> wrote:
>> On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:
>>
>> > Le 15/07/2009 19:40, clipka nous fit lire :
>> >> Le_Forgeron <jgr### [at] freefr> wrote:
>> >>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate
>> >>> freebsd 7.2 and lower for not having it ? (no assertion about 8.0)
>> >>
>> >> Sounds like a reasonable option :P (SCNR)
>> >>
>> >> I'd say it depends on how complicated it would be to fix. At any
>> >> rate, it's worth entering into the bugtracker as a compatibility
>> >> issue. As you seem to be into details to some degree, would you
>> >> mind...? kthxbye ;)
>> >>
>> >>
>> >>
>> > Entry add in bugtracker, as per request.
>>
>> I thank you for it ;)
>
> Looks like Le_Forgeron not only entered the issue, but already did a
> thorough analysis; I can only agree with all his conclusions: It should
> be a matter of ../configure identifying that CLOCK_PROCESS_CPUTIME_ID
> isn't available, and in that case not setting HAVE_CLOCK_GETTIME, but
> HAVE_GETRUSAGE instead; as the code seems to be well prepared for
> dealing with clock_gettime() being unavailable, issues worse than
> possibly misleading statistics are not to be expected.
>
> So no need to loathe freebsd for this :)
sorry, did you read all new posts in this thread?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |