From: Peter V. <pet...@ya...> - 2010-07-29 20:21:14
|
On 2010-07-09, Sean McBride <se...@ro...> wrote: > [...] > Then I tried another build with all the same settings > except using clang and there are hundreds of errors: > <http://www.cdash.org/CDash/viewBuildError.php?buildid=660226> > > I'm not a C++ expert, but many of the errors look legitimate. > > Anyone interested in helping getting this building? I've looked at these errors, and it seems like most of them happen in two cases: the first is when a method of a templated parent class is called (from a method of a derived class). This is easily fixed by prefixing that call with the parent class name and "::" which I've actually done in a few cases (and SVN committed). (In those cases, with the added prefix the code even becomes more readable since it's now clear where the method belongs to.) The second case, and actually the cause of most errors from the clang compiler in vxl, is when a vnl_matrix_fixed<T,n,m> is used where a vnl_matrix<T> and is expected, and similarly for vnl_vector<T> & vnl_vector_fixed<T,n>. Although there is the following convertor: operator const vnl_vector_ref<T>() const in class vnl_vector_fixed, and vnl_vector_ref is a derived class from vnl_vector, the clang compiler does not automatically use this to allow a vnl_vector_fixed in contexts where a vnl_vector is expected. Again, I've modified some of these cases, thereby also cleaning up a bit, in those cases where mixing vnl_vector and vnl_vector_fixed was not a good idea. In most cases, I've inserted an explicit vnl_vector (or vnl_matrix) constructor, which costs a memcopy; in most cases these should be replaced by using the as_ref() method of vnl_vector_fixed to avoid the memcopy; I'll do that one of these days. From yesterday's dashboard of the clang compiler, it seems like these modifications will help to reduce the number of errors. (And the other builds look very green today -- seems nothing got broken.) To be continued... Any feedback is of course welcome! And please keep us informed about your clang+vxl experiences. -- Peter. |
From: Sean M. <se...@ro...> - 2010-07-30 19:51:28
|
On Thu, 29 Jul 2010 20:21:06 +0000, Peter Vanroose said: >> Then I tried another build with all the same settings >> except using clang and there are hundreds of errors: >> <http://www.cdash.org/CDash/viewBuildError.php?buildid=660226> >> >> I'm not a C++ expert, but many of the errors look legitimate. >> >> Anyone interested in helping getting this building? > >I've looked at these errors, and > > *SNIP* > >From yesterday's dashboard of the clang compiler, it seems like these >modifications will help to reduce the number of errors. (And the other >builds look very green today -- seems nothing got broken.) >To be continued... Peter, Thanks a lot for looking at this and fixing some issues! It's indeed much better now, instead of reaching the dashboard max of 500, there are now "only" 354 errors: <http://www.cdash.org/CDash/viewBuildError.php?buildid=680234> That may also be due to the fact that I updated my build of clang. They are fast improving their C++ support. One error is repeated often and looks simple enough to fix: /.../vxl/contrib/prip/vmap/vmap_ptr_sequences.h:295:5: error: use of undeclared identifier 'set_begin' set_begin(new pointer[arg_size]) ; ^ this-> It appears to be saying "this->" must be added. Likely some of the errors are bugs in clang. Just this week several of the VTK developers got VTK building with clang... There were two issues that were clang bugs, and the clang team fixed them each within a day, and now VTK builds! Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Peter V. <pet...@ya...> - 2010-07-30 21:58:59
|
Sean McBride <se...@ro...> wrote: > Thanks a lot for looking at this and fixing some issues! > It's indeed much better now, instead of reaching the > dashboard max of 500, there are now "only" 354 errors Well, of course, I didn't add all necessary ".as_ref()"s, but you can figure out for yourself (based on the compiler errors) where the other ones are needed. > One error is repeated often and looks simple enough to fix: > > /.../vxl/contrib/prip/vmap/vmap_ptr_sequences.h:295:5: > error: use of > undeclared identifier 'set_begin' > set_begin(new pointer[arg_size]) > ; > ^ > this-> > > It appears to be saying "this->" must be added. OK, did that (as well as some similar ones in that file). Most likely, contrib/prip/vmap will "never" compile with the clang compiler since it's using some "advanced" C++ stuff, so don't put too much effort into fixing that library's build. -- Peter. |
From: Sean M. <se...@ro...> - 2010-08-02 20:49:54
|
On Fri, 30 Jul 2010 21:58:50 +0000, Peter Vanroose said: >Most likely, contrib/prip/vmap will "never" compile with the clang >compiler since it's using some "advanced" C++ stuff, so don't put too >much effort into fixing that library's build. In that case, I've set BUILD_CONTRIB and BUILD_PRIP to off and now there's just a small number of errors: <http://www.cdash.org/CDash/viewBuildError.php?buildid=682893> BTW, what is vxl's minimum requirement? C++98? C++03? C++0x? clang currently claims full support of C++03 (except 'export'): <http://clang.llvm.org/cxx_status.html> Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Peter V. <pet...@ya...> - 2010-08-02 22:17:21
|
Sean McBride <se...@ro...> wrote: > In that case, I've set BUILD_CONTRIB and BUILD_PRIP to off I guess you may leave BUILD_CONTRIB on, and just set BUILD_PRIP off. > clang currently claims full support of C++03 (except 'export'): Don't know what C++ version vxl currently claims to support. Actually, vxl/core is on purpose not using some more "exotic" C++ features. For more information, see Section 3.3 of http://public.kitware.com/vxl/doc/development/books/core/book_3.html -- Peter. |
From: Sean M. <se...@ro...> - 2010-08-04 21:50:39
|
On Mon, 2 Aug 2010 22:17:13 +0000, Peter Vanroose said: >> In that case, I've set BUILD_CONTRIB and BUILD_PRIP to off > >I guess you may leave BUILD_CONTRIB on, and just set BUILD_PRIP off. Done. >> clang currently claims full support of C++03 (except 'export'): > >Don't know what C++ version vxl currently claims to support. >Actually, vxl/core is on purpose not using some more "exotic" C++ features. >For more information, see Section 3.3 of http://public.kitware.com/vxl/ >doc/development/books/core/book_3.html So it seems to me that clang should be able to build it... though as I've said, it's C++ support is not perfect. Anyway, today's dashboard has only 8 errors now that BUILD_PRIP is off, and really it's just 2 errors repeated: <http://www.cdash.org/CDash/viewBuildError.php?buildid=684736> One looks like it might be a clang bug: /vxl/core/vil/vil_math.h:42:18: error: invalid operands to binary expression ('std::complex<float> const' and 'std::complex<float>') if (pixel<min_value) ~~~~~^~~~~~~~~~ Odd that a difference in constness should make comparison fail... but I'm no C++ expert... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Peter V. <pet...@ya...> - 2010-08-05 09:30:26
|
> [...] it's just 2 errors repeated: > <http://www.cdash.org/CDash/viewBuildError.php?buildid=684736> > One looks like it might be a clang bug: > core/vil/vil_math.h:42:18: error: > invalid operands to binary expression > ('std::complex<float> const' and 'std::complex<float>') > if (pixel<min_value) This is because the "complex" type has no comparisons, so indeed the "<" operator does not exist for arguments of datatype std::complex<float>. This line 42 should never have been instantiated for the datatype complex, so it's indeed a clang bug that it tries to instantiate. Could be "easily" fixed by adding (conditionally, only for clang) a "dummy" instance for the "<" operator to the file vcl/vcl_complex.h (or actually: to a file included by that one). That's exactly what the vcl library is meant for: fixing compiler bugs. The other error is a clang bug as well: core/vpdl/vpdl_kernel_base.h:55:5: error: use of undeclared identifier 'vpdt_size' assert(vpdt_size(s) == this->dimension() || num_components() == 0); there *is* a template specialisation for the global function vpdt_size(T) with T=float and equally for T=double: see lines 52 and 53 of core/vpdl/vpdt/vpdt_access.h The reason that this is so difficult for the compiler is the following: s has datatype "vector" which is an in-class typedef for typename vpdt_field_default<T,n>::type At template instantiation time, this type is either vnl_vector<float> or vnl_matrix<float> or float (or similary with double). For each of these, a specialisation is available for the function vpdt_size(s). It should be easy to write a short, selfcontained C++ file which has this problem; that would help the clang developers to work on it. Meanwhile, I've no immediate suggestions on how to fix this inside vxl... -- Peter. |
From: Sean M. <se...@ro...> - 2010-08-05 16:03:36
|
On Thu, 5 Aug 2010 09:30:17 +0000, Peter Vanroose said: >> [...] it's just 2 errors repeated: >> <http://www.cdash.org/CDash/viewBuildError.php?buildid=684736> >> One looks like it might be a clang bug: >> core/vil/vil_math.h:42:18: error: >> invalid operands to binary expression >> ('std::complex<float> const' and 'std::complex<float>') >> if (pixel<min_value) > >This is because the "complex" type has no comparisons, so indeed the "<" >operator does not exist for arguments of datatype std::complex<float>. >This line 42 should never have been instantiated for the datatype >complex, so it's indeed a clang bug that it tries to instantiate. >Could be "easily" fixed by adding (conditionally, only for clang) a >"dummy" instance for the "<" operator to the file vcl/vcl_complex.h (or >actually: to a file included by that one). That's exactly what the vcl >library is meant for: fixing compiler bugs. > >The other error is a clang bug as well: >core/vpdl/vpdl_kernel_base.h:55:5: error: > use of undeclared identifier 'vpdt_size' > assert(vpdt_size(s) == this->dimension() || num_components() == 0); > > there *is* a template specialisation for the global function vpdt_size >(T) with T=float and equally for T=double: see lines 52 and 53 of core/ >vpdl/vpdt/vpdt_access.h > >The reason that this is so difficult for the compiler is the following: >s has datatype "vector" which is an in-class typedef for > typename vpdt_field_default<T,n>::type >At template instantiation time, this type is either vnl_vector<float> or >vnl_matrix<float> or float (or similary with double). For each of these, >a specialisation is available for the function vpdt_size(s). > >It should be easy to write a short, selfcontained C++ file which has >this problem; that would help the clang developers to work on it. >Meanwhile, I've no immediate suggestions on how to fix this inside vxl... First, thanks once more for all this help! Before adding clang-specific workarounds to vxl, let's create, as you say, short self-contained test cases. Do you have time to do so? I suspect you could do it much faster than I (my C++-foo is weak). :) I'm on the clang list and have a bugzilla account with them, so I could take your test case and 'take it from there'. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Peter V. <pet...@ya...> - 2010-08-05 22:10:29
|
OK, done: see file vcl/tests/test_typename.cxx Not sure, of course, whether this fails compiling with the clang compiler. -- Peter. --- Sean McBride <se...@ro...> wrote: > Before adding clang-specific workarounds to vxl, let's > create, as you say, short self-contained test cases. > Do you have time to do so? I > suspect you could do it much faster than I (my C++-foo is > weak). :) > > I'm on the clang list and have a bugzilla account with > them, so I could take your test case and 'take it from there'. |
From: Sean M. <se...@ro...> - 2010-08-06 15:10:55
|
Peter, Thanks for creating the example. However, the example compiles. Both with clang and gcc and the online comeau compiler too. (Though I did rename test_typename_main to just main.) I guess there is some small subtle difference between your test and vxl itself... Sean On Thu, 5 Aug 2010 22:10:19 +0000, Peter Vanroose said: >OK, done: see file vcl/tests/test_typename.cxx >Not sure, of course, whether this fails compiling with the clang compiler. > >-- Peter. > > >--- Sean McBride <se...@ro...> wrote: > >> Before adding clang-specific workarounds to vxl, let's >> create, as you say, short self-contained test cases. >> Do you have time to do so? I >> suspect you could do it much faster than I (my C++-foo is >> weak). :) >> >> I'm on the clang list and have a bugzilla account with >> them, so I could take your test case and 'take it from there'. |
From: Peter V. <pet...@ya...> - 2010-08-10 09:33:08
|
I moved up the specialisations for operator<(complex,complex) (which apparently were already in core/vil/tests/test_image_resource.cxx) to just after #include <complex>, and that seems to have solved the problem of the clang compiler. Apparently, clang wants to see template specialisations before they are needed, while gcc is happy with them appearing further down the file. So no need (for the time being) to create a clang-specific file in the vcl directory tree. -- Peter. |
From: Sean M. <se...@ro...> - 2010-08-10 21:53:39
|
On Tue, 10 Aug 2010 09:33:00 +0000, Peter Vanroose said: >I moved up the specialisations for operator<(complex,complex) (which >apparently were already in core/vil/tests/test_image_resource.cxx) to >just after #include <complex>, and that seems to have solved the problem >of the clang compiler. >Apparently, clang wants to see template specialisations before they are >needed, while gcc is happy with them appearing further down the file. > >So no need (for the time being) to create a clang-specific file in the >vcl directory tree. Peter, Great! I didn't like the idea of compiler-specific conditionalization, at least not before filing a bug with the clang people. So there are still some warnings, which I took a looksie at. For some, you just need to change a 'char*' to 'const char*': /.../vxl/core/vil1/file_formats/vil1_iris.h:49:62: warning: conversion from string literal to 'char *' is deprecated [-Wdeprecated] vil1_iris_generic_image(vil1_stream* is, char* imagename = ""); ^ This looks legit too: /.../vxl/core/vgui/vrml/vgui_vrml_draw_visitor.cxx:283:13: warning: use of logical && with constant operand; switch to bitwise & or remove constant [-Wconstant-logical-operand] if (parts && (QvCone::BOTTOM | QvCone::ALL)) ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ And this is probably worth looking at: /.../vxl/contrib/rpl/rsdl/rsdl_bins.txx:315:15: warning: array comparison always evaluates to false [-Wtautological-compare] if ( bin_lo == bin_hi ) { ^ Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Sean M. <se...@ro...> - 2010-10-26 17:25:38
|
Peter, I've noticed that the clang build has not been building for some time now, with more and more errors over time. I've just updated my build of clang, hoping some of them would go away, but there are still errors. There's also a new warning, that is repeated many times: "warning: in-class initializer for static data member of type 'const float' is a C++0x extension [-Wc++0x-extensions]" By default, clang assumes the C++03 standard, and so the warning is correct. Which version of C++ is VXL supposed to be? Should I: - tell clang to build as C++0x? - disable the warning? - leave the warning there so you guys can fix them? Cheers, Sean |
From: Peter V. <pet...@ya...> - 2010-10-27 08:47:36
|
Sean, I just took a look at the errors and warnings of yesterday's clang build on the dashboard; we should mainly be worried by problems in "core", although those in "contrib" should not be neglected of course. Currently, the 17 build errors (actually: just 2 unique ones) are all in contrib/gel/mrv/vpgl/{ihog,icam} which is very "bleeding edge" since it's added just recently to the SVN repository, and most likely not intensively tested on multi-platforms. That's exactly what the dashboard is for, and more specifically your clang dashboard submissing: it helps correcting those "early code" errors in an early stadium. One of the two errors is solved by a modification in core/vgl/algo; I'll do that. For the other one: someone with knowledge of OpenCL should have a look. You're right about the C++03 warning; this is a more general issue than just the clang compiler, and I personally don't know how to proceed with this. It should probably be a discussion topic on this forum. So in summary: don't be worried too much: it seems like vxl (core & most of contrib) is currently doing fine with the clang compiler. ========================================== Details: (no need to read on for those not interested in details) First the errors: actually there are only 2, the 15 others being either duplicates or consequences of these 2: First error: contrib/gel/mrc/vpgl/ihog/ihog_transform_2d.cxx:126:51: error: no viable conversion from 'vnl_double_2x3' to 'const vnl_matrix<double>' vgl_h_matrix_2d<double>::set_affine(M23); } ^~~ This is solved by adding the following overloaded method to vgl/algo/vgl_h_matrix_2d.h (& .txx): template <class T> vgl_h_matrix_2d<T>& vgl_h_matrix_2d<T>::set_affine(vnl_matrix_fixed<T,2,3> const& M23) with the same implementation as the existing set_affine(). (I'm going to SVN commit this change later today.) Actually, that method should have been there a long time ago; it should be the default one, the overloaded one should be seen as deprecated. Second error: contrib/gel/mrc/vpgl/icam/icam_ocl/icam_ocl_search_manager.h:89:26: error: function cannot return array type 'cl_int4' (aka 'int32_t [4]') cl_int4 image_para_flag() {return *image_para_flag_;} ^ I've already noticed this error to pop up in several places. It has to do with and (internal) OpenCL choice about byte interpretation and mapping onto C++ data types. Could someone familiar with OpenCL look into this? Maybe redefine "cl_int4": instead of as "int32_t[4]", it should maybe become something like "struct cl_int4 { int32_t[4] }" or so? Warnings: core/vnl/vnl_numeric_traits.h:340:22: warning: in-class initializer for static data member of type 'const float' is a C++0x extension [-Wc++0x-extensions] static const float zero VCL_STATIC_CONST_INIT_FLOAT_DECL(0.0F); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This one is popping up a lot of times, so it would indeed be good to correct this once and forever. Any suggestions from the C++ and the C++03 standard specialists? -- Peter. --- On 2010-10-26 Sean McBride <se...@ro...> wrote: > I've noticed that the clang build has not been building for > some time now, with more and more errors over time. > > I've just updated my build of clang, hoping some of them > would go away, but there are still errors. > There's also a new warning, that is repeated many times: > > "warning: in-class initializer for static data member of > type 'const float' is a C++0x extension [-Wc++0x-extensions]" > > By default, clang assumes the C++03 standard, and so the > warning is correct. Which version of C++ is VXL supposed > to be? Should I: > - tell clang to build as C++0x? > - disable the warning? > - leave the warning there so you guys can fix them? |
From: Amitha P. <ami...@us...> - 2010-10-29 11:41:40
|
On 10/27/2010 04:47 AM, Peter Vanroose wrote: > Warnings: > > core/vnl/vnl_numeric_traits.h:340:22: warning: > in-class initializer for static data member of type 'const float' is a C++0x extension [-Wc++0x-extensions] > static const float zero VCL_STATIC_CONST_INIT_FLOAT_DECL(0.0F); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > This one is popping up a lot of times, so it would indeed be good to correct this once and forever. Any suggestions from the C++ and the C++03 standard specialists? This macro is usually only defined for gcc, which allows const float initializers as an extension even on C++98. There is a try-compile during configure time that tries to figure out if the compiler supports it or not. However, the test only looks for a successful exit from the compiler (i.e., no errors), and so the test would not catch the warning. Newer CMake versions have a way of doing try-compiles that parse the output of the test case. (I'm not sure exactly which version.) If we were willing to update the required version of CMake, we could update the try-compile to fail if there are warnings or errors. The alternative is to stick with true C++98 and not allow const float initializers at all. This would be a shame, though, because it looks like C++0x will allow them. Amitha. |
From: Sean M. <se...@ro...> - 2011-01-17 16:55:49
|
Peter, I've noticed that our clang-based vxl dashboards have been red for a few weeks. There seems to be 2 basic problems: Undefined symbols: "_timing_", referenced from: _v3p_netlib_dsaupd_ in libv3p_netlib.a(dsaupd.o) /Users/builder/kitware/vxl/core/vgui/examples/example_gllist_tableau.cxx: 19:10: fatal error: 'GL/gl.h' file not found #include <GL/gl.h> ^ 1 error generated. Have you guys just not had time to look at these, or is there a problem in my configuration perhaps? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Peter V. <pet...@ya...> - 2011-01-18 17:40:19
|
Sean, > Undefined symbols: > "_timing_", referenced from: > _v3p_netlib_dsaupd_ in libv3p_netlib.a(dsaupd.o) Yes, I've noticed this, too. The struct "timing_" is referred to in several .c files in netlib/arpack as "Extern struct { ..... }". It's defined (that is, used without the "Extern") in netlib/arpack/timing_com.c Apparently, on your system, that's not sufficient to make it visible (i.e., to make it a "public symbol") in the object file timing_com.o Or maybe that latter file is not part of the build on your system? Or does your compiler require a specific keyword ("export" or the like) in timing_com.c ? > [...]/vxl/core/vgui/examples/example_gllist_tableau.cxx: > 19:10: fatal error: 'GL/gl.h' file not found > #include <GL/gl.h> This could have been a mistake in core/vgui/examples/CMakeLists.txt: if GL is not available on a system, or has not been activated in CMakeCache.txt, files including GL/gl.h should never be considered for compiling. So that entry (in the CMakeLists.txt file) should maybe be moved into a conditional section, conditional on OPENGL_FOUND. *BUT* since core/vgui/CMakeLists.txt has SUBDIRS(examples) inside an IF(OPENGL_FOUND), on your system OPENGL is indeed available. Which should mean that GL/gl.h is in the include path, since that's one of the conditions for OPENGL_FOUND to be set. *BUT*, digging a bit further, and looking in CMake's Modules/FindOpenGL.cmake, I notice (on line 58) that For APPLE, the file searched for is actually OpenGL/gl.h instead of GL/gl.h So actually, we'll have to modify all source files #including <GL/gl.h>, replacing that #include into something like: #ifdef APPLE // or what should we use here????? #include <OpenGL/gl.h> #else #include <GL/gl.h> #endif Maybe you'll have to add a section (named "APPLE" or "CLANG" or the like) to vcl/vcl_compiler.h -- Peter. |
From: Sean M. <se...@ro...> - 2011-01-18 18:05:57
|
On Tue, 18 Jan 2011 17:40:11 +0000, Peter Vanroose said: >> Undefined symbols: >> "_timing_", referenced from: >> _v3p_netlib_dsaupd_ in libv3p_netlib.a(dsaupd.o) > >Yes, I've noticed this, too. >The struct "timing_" is referred to in several .c files in netlib/arpack >as "Extern struct { ..... }". > >It's defined (that is, used without the "Extern") in netlib/arpack/ >timing_com.c >Apparently, on your system, that's not sufficient to make it visible >(i.e., to make it a "public symbol") in the object file timing_com.o >Or maybe that latter file is not part of the build on your system? >Or does your compiler require a specific keyword ("export" or the like) >in timing_com.c ? Poking around the dashboard, I see that this happens with another Mac dashboard: <http://www.cdash.org/CDash/viewNotes.php?buildid=827326> So it's probably not anything particular to my particular system/compiler. I'm not really sure what would be causing this, and don't have the time to look right now... >> [...]/vxl/core/vgui/examples/example_gllist_tableau.cxx: >> 19:10: fatal error: 'GL/gl.h' file not found >> #include <GL/gl.h> > >This could have been a mistake in core/vgui/examples/CMakeLists.txt: if >GL is not available on a system, or has not been activated in >CMakeCache.txt, files including GL/gl.h should never be considered for >compiling. So that entry (in the CMakeLists.txt file) should maybe be >moved into a conditional section, conditional on OPENGL_FOUND. > >*BUT* since core/vgui/CMakeLists.txt has SUBDIRS(examples) inside an IF >(OPENGL_FOUND), on your system OPENGL is indeed available. Which should >mean that GL/gl.h is in the include path, since that's one of the >conditions for OPENGL_FOUND to be set. > >*BUT*, digging a bit further, and looking in CMake's Modules/ >FindOpenGL.cmake, I notice (on line 58) that For APPLE, the file >searched for is actually OpenGL/gl.h instead of GL/gl.h > >So actually, we'll have to modify all source files #including <GL/gl.h>, >replacing that #include into something like: > >#ifdef APPLE // or what should we use here????? > #include <OpenGL/gl.h> >#else > #include <GL/gl.h> >#endif > >Maybe you'll have to add a section (named "APPLE" or "CLANG" or the >like) to vcl/vcl_compiler.h Your analysis seems correct. I took a look at what VTK does and they've created a file called vtkgl.h which they include anywhere they want OpenGL. vtkgl.h looks basically like this: #if defined(__APPLE__) # include <OpenGL/gl.h> #else # include <GL/gl.h> #endif That seems like a good solution to me. Thanks, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Peter V. <pet...@ya...> - 2011-01-18 22:56:43
|
Sean McBride <se...@ro...> wrote: > I took a look at what VTK does and they've created a file > called vtkgl.h which they include anywhere they want OpenGL. Thanks for that suggestion! It led me to a similar file in vgui: vgui_gl.h, which I was unaware of. I've replaced the offending #include with this one. This should fix the problem on Mac. -- Peter. |
From: Peter V. <pet...@ya...> - 2010-10-30 12:20:22
|
On the vxl dashboard, at least two builds have problems with OpenCL types cl_int4 and cl_float4, as used on lines 86 & 87 of contrib/gel/mrc/vpgl/icam/icam_ocl/icam_ocl_search_manager.h: http://www.cdash.org/CDash/viewBuildError.php?buildid=763793 and http://www.cdash.org/CDash/viewBuildError.php?buildid=763290 (Both are MAC bulds.) In my copy of CL/cl_platform.h, cl_int4 is typedefed as (a union containing) struct { cl_int x, y, z, w; } Maybe we should, at least for the failing compilers, use a typedef to this struct instead of the cl_int4 declaration provided to those compilers on the MAC? -- Peter. -- --- Den tis 2010-10-26 skrev Sean McBride <se...@ro...>: > Från: Sean McBride <se...@ro...> > Ämne: Re: clang now compiles (was: Mac OS X dashboards & adding clang support) > Till: p.v...@ie..., "Peter Vanroose" <pet...@ya...> > Kopia: "vxl maintainers" <vxl...@li...> > Datum: tisdag 26 oktober 2010 19:25 > Peter, > > I've noticed that the clang build has not been building for > some time > now, with more and more errors over time. > > I've just updated my build of clang, hoping some of them > would go away, > but there are still errors. There's also a new > warning, that is > repeated many times: > > "warning: in-class initializer for static data member of > type 'const > float' is a C++0x extension [-Wc++0x-extensions]" > > By default, clang assumes the C++03 standard, and so the > warning is > correct. Which version of C++ is VXL supposed to > be? Should I: > - tell clang to build as C++0x? > - disable the warning? > - leave the warning there so you guys can fix them? > > Cheers, > > Sean > > > |
From: Matt L. <mat...@ki...> - 2010-08-06 16:24:00
|
Sean, Maybe it's a simple issue of not including that header that contains vpdt_size(s). It doesn't look like vpdl_kernel_base.h includes any files that recursively include vpdt_access.h. Try adding #include <vpdl/vpdt/vpdt_access.h> near the top of vpdl/vpdl_kernel_base.h. --Matt On Fri, 2010-08-06 at 11:10 -0400, Sean McBride wrote: > Peter, > > Thanks for creating the example. However, the example compiles. Both > with clang and gcc and the online comeau compiler too. (Though I did > rename test_typename_main to just main.) > > I guess there is some small subtle difference between your test and vxl > itself... > > Sean > > > On Thu, 5 Aug 2010 22:10:19 +0000, Peter Vanroose said: > > >OK, done: see file vcl/tests/test_typename.cxx > >Not sure, of course, whether this fails compiling with the clang compiler. > > > >-- Peter. > > > > > >--- Sean McBride <se...@ro...> wrote: > > > >> Before adding clang-specific workarounds to vxl, let's > >> create, as you say, short self-contained test cases. > >> Do you have time to do so? I > >> suspect you could do it much faster than I (my C++-foo is > >> weak). :) > >> > >> I'm on the clang list and have a bugzilla account with > >> them, so I could take your test case and 'take it from there'. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Sean M. <se...@ro...> - 2010-08-06 17:03:20
|
On Fri, 6 Aug 2010 12:00:34 -0400, Matt Leotta said: >Maybe it's a simple issue of not including that header that contains >vpdt_size(s). It doesn't look like vpdl_kernel_base.h includes any >files that recursively include vpdt_access.h. Try adding > >#include <vpdl/vpdt/vpdt_access.h> > >near the top of vpdl/vpdl_kernel_base.h. Matt, You're right! That took care of those errors. Will someone commit? Now it's just the 'complex' one: <http://www.cdash.org/CDash/viewBuildError.php?buildid=686725> /.../vxl/core/vil/vil_math.h:42:18: error: invalid operands to binary expression ('std::complex<float> const' and 'std::complex<float>') if (pixel<min_value) ~~~~~^~~~~~~~~~ Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Peter V. <pet...@ya...> - 2010-08-06 17:15:15
|
OK, done. -- Peter. --- Sean McBride <se...@ro...> wrote: > Matt Leotta said: > > Maybe it's a simple issue of not including that header that contains > > vpdt_size(s). It doesn't look like vpdl_kernel_base.h includes any > > files that recursively include vpdt_access.h. Try adding > > #include <vpdl/vpdt/vpdt_access.h> > > near the top of vpdl/vpdl_kernel_base.h. > > You're right! That took care of those errors. > Will someone commit? |
From: Peter V. <pet...@ya...> - 2010-08-07 08:35:39
|
> Now it's just the 'complex' one: > > core/vil/vil_math.h:42:18: error: invalid operands to binary > expression ('std::complex<float> const' and 'std::complex<float>') > if (pixel<min_value) > > ~~~~~^~~~~~~~~~ Try adding the following to vcl/vcl_complex.h : template <class T> bool operator<(vcl_complex<T> const& a, vcl_complex<T> const& b) { return false; } If that fixes the compiler error, we'll have to create a new subdirectory of vcl (in the stype of the ones already present, e.g. sunpro) and put the above (and maybe some more of those operators) in a file in that subdir; then conditionally include that file from vcl/vcl_complex.h We'll also need to modify vcl/vcl_compiler.h Which macro is set by the clang compiler that can be used there? -- Peter. |