The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Thomas Klausner - 2011-02-25
Last edited by William F Pokorny - 2016-11-05
FS#195 - povray-3.7.0rc3 incompatible with NetBSD
While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:
1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe)
2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable.
3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix).
4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3.
5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is
#ifdef HAVE_SYS_WAIT_H
# include <sys/wait.h>
#endif
but this also needs a check in the configure script.
Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html.
Backtrace is
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004ac479 in boost::gregorian::date::date ()
(gdb) bt
#0 0x00000000004ac479 in boost::gregorian::date::date ()
#1 0x00000000004d29f7 in boost::gregorian::date::date ()
#2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName ()
#6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName ()
#7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName ()
#8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= ()
#9 0x00007f7ffd80d9cf in thread_proxy ()
from /usr/pkg/lib/libboost_thread.so.1.45.0
#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>)
at /archive/cvs/src/lib/libpthread/pthread.c:473
#11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12
Please advise on how to proceed.
Saturday, 05 November 2016, 12:33 GMT
Reason for closing: Fixed
Additional comments about closing:
I believe fixed in 3.7.1 master. See closed github issues:
https://github.com/POV-Ray/po vray/issues/8
and
https://github.com/POV-Ray/p
ovray/issues/31
If still a
compile issue, please open a new github
issue specific to it. Thanks.
What compiler and system/C/C++ library versions are you using?
I'm using the default compiler coming with that NetBSD version which is
gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb2 20081120)
It's using the C++ library coming with that version of gcc.
NetBSD has its own libc; there are no particular versions of that, they use the same numbering as the NetBSD release.
In the meantime, I've upgraded my NetBSD to 5.99.55, which uses
gcc (NetBSD nb2 20110806) 4.5.3
The compilation fails differently with this version. Many problems stem from the fact that the compiler can't decide between the shared_ptr implementations coming with gcc and boost (1.46.1).
For example:
In file included from ../../source/backend/scene/scene.h:106:0,
from ../../source/backend/parser/parse.h:122, from ../../source/backend/shape/fpmetric.h:100, from shape/fpmetric.cpp:103:../../source/backend/scene/view.h:286:10: error: reference to 'shared_ptr' is ambiguous
/scratch/nih/povray/work/.buildlink/include/boost/exception/exception.hpp:138:11: error: candidates are: template<class T> class boost::shared_ptr
/usr/include/g++/bits/shared_ptr_base.h:65:11: error: template<class _Tp> class std::shared_ptr
../../source/backend/scene/view.h:286:10: error: 'shared_ptr' does not name a type
../../source/backend/scene/threaddata.h:219:10: error: reference to 'shared_ptr' is ambiguous
/scratch/nih/povray/work/.buildlink/include/boost/exception/exception.hpp:138:11: error: candidates are: template<class T> class boost::shared_ptr
/usr/include/g++/bits/shared_ptr_base.h:65:11: error: template<class _Tp> class std::shared_ptr
../../source/backend/scene/threaddata.h:219:10: error: 'shared_ptr' does not name a type
../../source/backend/scene/threaddata.h:223:3: error: reference to 'shared_ptr' is ambiguous
/scratch/nih/povray/work/.buildlink/include/boost/exception/exception.hpp:138:11: error: candidates are: template<class T> class boost::shared_ptr
/usr/include/g++/bits/shared_ptr_base.h:65:11: error: template<class _Tp> class std::shared_ptr
../../source/backend/scene/threaddata.h:223:3: error: 'shared_ptr' does not name a type
These errors make so much noise that it's hard to see any other errors.
I see that vfe/unix/syspovconfig.h tries to make it clear, which shared_ptr to use, but it seems that doesn't work for some reason.
Have you seen this news group thread?
http://news.povray.org/povray.unix/thread/%3Cweb.4e5a645d75e998c43b47249a0%40news.povray.org%3E/
If this doesn't get you going, please reply back in this forum. It does appear to clear up issues like these ... in the mean time the configure phase of the build process is being reviewed for a possible fix.
If gcc 4.5 cannot decide between boost::shared_ptr amd std::shared_ptr, there seems to be something fishy with NetBSD's build environment: According to the gcc 4.5.3 documentation, C++0x extensions (which include std::shared_ptr) should be off by default.
IIRC there was something about this problem (on FreeBSD, I think) on the boost mailing list a few weeks ago. It might be worth checking if the most recent boost 1.47 or their current trunk code contain a workaround for this issue already.