CGAL users discussion list

[Jeffrey Bush <>]

Setup install path: doing a bit more research %ProgramW6432% does not exist on 32-bit systems. So the best option is to use %ProgramW6432% if defined, else use %ProgramFiles% (hopefully your installer system allows for that logic). For testing installers, you could just use VirtualPC with the free images supplied at http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11575 which are all 32-bit images and last for 90 days or unlimited by using undo disks.

Boost auto-linking: this time around everything worked. I followed the Windows-specific guide. The main differences I saw were using Tom's Boost libraries instead of Boostpro and setting some additional environmental variables that I normally set in . I think Boostpro's version number was off.

AABB_demo is now working on Windows. Soon to test on CentOS machine (had to wait for admins to install some of the prerequisites). I think the bad image format thing didn't show up during the compile since the LIB was right, but the DLL used was wrong. The compiler/linker doesn't look at the DLL.

Intellisense: I don't really have any experience with this but doing a quick Google search I come up with using #ifndef __INTELLISENSE__ .... #endif to hide code from Intellisense (http://stackoverflow.com/questions/6496524/hide-a-c-code-block-from-intellisense) and a general article on the Intellisense compiler in VS2010 on the MSDN blog (http://blogs.msdn.com/b/vcblog/archive/2011/03/29/10146895.aspx). On calling it programmatically, I have no idea.

** New Problems **

So I successfully built the project files and then compiled the debug version in VS. I had WITH_examples and WITH_demos enabled, which made it a really long process, but I found problems and warnings. I have attached full error, warning, and build logs. I highlight the main issues below (the actually logs show some additional errors due to memory limits being hit the first time and not specifying the right zlib lib file the first time). These don't effect me immediately but I thought you should know about them.

Error: algebraic_segments and algebraic_curves: specialization conversions not possible

error C2440: 'specialization' : cannot convert from 'CORE::BigRat std::_Pair_base<_Ty1,_Ty2>::* ' to 'CORE::BigRat std::pair<_Ty1,_Ty2>::* ' C:\CGAL\CGAL-4.1\include\CGAL\Algebraic_kernel_d\LRU_hashed_map.h line 89

error C2440: 'specialization' : cannot convert from 'CORE::BigRat std::_Pair_base<_Ty1,_Ty2>::* ' to 'CORE::BigRat std::pair<_Ty1,_Ty2>::* ' C:\CGAL\CGAL-4.1\include\CGAL\Algebraic_kernel_d\LRU_hashed_map.h line 89

Error: Kinetic_Delaunay_triangulation_3: argument type problems

error C2665: 'CGAL::Kinetic::internal::Delaunay_3_edge_flip_event<KD,RS>::Delaunay_3_edge_flip_event' : none of the 2 overloads could convert all the argument types C:\CGAL\CGAL-4.1\include\CGAL\Kinetic\internal\Delaunay_triangulation_base_3.h line 877

Error: Many demos/examples unable to compile in debug mode due to "number of sections exceeded object file format limit" (error number C1128 - they have suggestions for fixing). Note that they say it is 3x easier to hit this limit on 64-bit then 32-bit and without debug mode is a lot better. Also splitting up source files into multiple files helps. The most straight-forward solution is to add the command line argument /bigobj for compiliation of these projects.

Projects: scene_nef_polyhedron_item, mesh_two_implicit_spheres_with_balls, mesh_polyhedral_domain_with_features, poisson_reconstruction, offIO, nefIO, mesh_3_plugin, mesh_3_demo_mesh_3_optimization_plugin, handling_double_coordinates, glide, cube_offset, corefinement_plugin, connect_polygon, complex_construction, PS_demo_poisson_plugin

Warning: Kinetic_regular_triangulation_3 - type name first seen using 'struct' now seen using 'class' - Seems like something that should be addressed, one should be renamed so that they aren't conflicting

warning C4099: 'CGAL::Kinetic::Regular_triangulation_3<TraitsT,VisitorT,TriangulationT>::Delaunay_visitor' : type name first seen using 'struct' now seen using 'class' C:\CGAL\CGAL-4.1\include\CGAL\Kinetic\Regular_triangulation_3.h 360

warning C4099: 'CGAL::Kinetic::Regular_triangulation_3<TraitsT>::Delaunay_visitor' : type name first seen using 'struct' now seen using 'class' C:\CGAL\CGAL-4.1\include\CGAL\Kinetic\Regular_triangulation_3.h 360

Warning: polyhedron_ex_parameterization and Taucs_parameterization - defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library

Some conflict in the C library being used in these projects

Warning: 99 warnings about conversion of __int64 to int and 329 warnings about conversion of size_t to (unsigned) int or long

This is a lot of errors/warnings about int usage problems, specifically about running on a 64-bit system probably. For a complete list of projects/lines with this error, see the attached xslx spreadsheet.

Warning: 4 warnings about conversion of double to float

Seems a bit more important to address since it effects 32 and 64 bit and Linux and Windows. Details in attached spreadsheet.

Warning: 23 warnings about forcing int / void* / CGAL::Sign to true / false as a performance warning

Add a cast to remove warning, but otherwise just a quirk of MSVC.

Warning: 373 warnings about decorated names exceeding length and being truncated

Probably nothing that can be done about this, but is a quirk of MSVC.

Jeff

On Fri, Feb 1, 2013 at 3:39 AM, Laurent Rineau (CGAL/GeometryFactory) <> wrote:

Le jeudi 31 janvier 2013 16:14:31 Jeffrey Bush a écrit :

> Thanks for your input. I had a long frustrating day yesterday and I may
> have taken some of it out on the list...
>

> *Installation path recommendation*: use %ProgramW6432% instead of the

> %ProgramFiles% directive. Basically always install to C:\Program Files\ (or
> whatever it has been renamed to) regardless if the OS is 32-bit or 64-bit.
> Your installer is 32-bit, but since you don't really have any compiled code
> (except the aux stuff which is already both) you should probably install to
> the native program files. This would have the side-effect of fixing the Qt
> cmake script issue.

For the next release, our setup.exe will install in:
  C:\Program Files\CGAL-4.2

However, I hope that modification of our setup program will not break on pure
32 bits Windows version. GeometryFactory no longer have pure 32 bits version
of Windows to test with.

> *Parenthesis issue*: sorry for blaming you, didn't realize this was a Qt
> issue! Sorry!

It is a CMake issue. CMake scripts for Qt4 are maintained and shipped in the
CMake distribution. I wonder if the Qt5 CMake scripts, maintained in the Qt5
distribution itself, will have any similar issues. I have not yet tested.

> *Alternate build path*: thanks for that tip as well. I didn't really

> understand the differentiation. I actually thought that was only where the
> finally binaries would be output to.

That is where any file generated by CMake will be put. The really "final
destination" of binaries is the result of the "installation" (with Microsoft
Visual Studio, that is when one "build" the "INSTALL" project in the CGAL
solution), and the installation process has its own destination directory,
that can be different from the other two.

> *Boost auto-linking*: not working. When configuring your cmake then going

> into VS and compiling I get numerous unresolved link errors, all related to
> boost. Specifying the appropriate boost libs in the linker input options in
> VS resolves the issue. Maybe something else is going on here... I am going
> to try to re-do all my Windows building following the Windows guide and
> maybe it will go away. I do recommend you link to the guide from the
> official manual though.

That is really strange. The auto-linking is used to construct the name of the
library from the version of the compiler and some compiler flags. For example,
The Boost.Thread library from Boost-1.50, when:
  - Microsoft Visual Studio 2008 (vc9) is used,
  - in Debug mode,
  - for a Boost library using the dynamic C and C++ runtimes,
  - and for a static version of Boost libraries,
then the name is:
  libboost_thread-vc90-mt-gd-1_50.lib

If that is:
  - Microsoft Visual Studio 2010 (vc10) is used,
  - in Release mode,
  - for a Boost library using the dynamic C and C++ runtimes,
  - and for a DLL version of Boost libraries,
then the name is:
  boost_thread-vc100-mt-1_50.lib


The FindBoost module, in CMake, is smart enough to find out what are the right
names of the Boost libraries to link with. However, in CGAL, even if we use
the FindBoost.cmake module, we have decided not to disable Boost auto-linking
features.

But Boost auto-linking is architecture-agnostic, so far. So users have to be
careful that the linking path contains the right directory to Boost libraries,
for the right architecture. Maybe you have 64 bits Boost libraries installed,
and try to link them with a 32 bits binary, or the reverse.


I am not sure that the choice to use Boost auto-linking within CGAL is the
right one. Maybe we should just use the names given by the CMake module
FindBoost. I currently do not have a lot of time to work on that subject.


Anyway, your troubles are probably due to a bad mix you may have configured
without noticing. Please double-check.

> *In terms of the AABB_demo*: I don't have a modified version of Windows, I

> am using MS Security Essentials anti-virus which is one of the most
> friendly (in terms of interacting with your system) ones out there. No
> broken hard drive (actually SSD and HDD). I tried to compile many times, in
> debug mode and in release mode. The only other time I have seen this error
> (in particular that error code) is when loading 32-bit DLLs from a 64-bit
> program or vice-a-versa.

Probably due to a bad mix of 32/64 binaries, indeed. Have a look at your
linker warnings: there should be an hint that something got wrong.

> After I rebuild CGAL I will see if maybe something
> like that is happening. Odd thing is that running that same demo in my
> CentOS virtual machine causes the entire virtual machine to crash... but
> that could be because of lack of most 3D graphics support. In both cases
> the AABB_examples were able to run just fine (on Windows and Linux). Now
> trying on a real CentOS machine (not virtual).

GeometryFactory do have a CentOS server (and Fedora desktops), so daily test
the Linux support. Our CentOS server is remote and headless, so I have never
tried to run any graphical application on it.

> *Creating project using CGAL:* I tried that and there were still some

> issues, but maybe rebuilding CGAL right will address them. One thing that I
> did notice and remember right away is that the MS Intellisense compiler has
> some issues with the CGAL headers. It shows compile errors that make no
> sense (if you consider the project properties).

My college working on Window with Visual Studio sees the same meaningless
errors reported by Intellisense. I do not have any clue how to understand and
fix those errors.

> Maybe you can detect the
> Intellisense compiler with some preprocessor macros to hide some of the
> CGAL header code from it? There are other reports of the Intellisense
> compiler not giving accurate results (the one that first comes to mind is
> that it treats all code as C++ even if it is compile as C/has a .c
> extension).

I do not find any way to run any automatic testing using the Intellisense
compiler. That will be very hard for the CGAL project to debug the errors
reported by that "compiler", and find workarounds. Is there any programmatic
way to call that Intellisense compiler externally to the Visual Studio IDE?

--
Laurent Rineau, PhD
R&D Engineer at GeometryFactory           http://www.geometryfactory.com/
Release Manager of the CGAL Project       http://www.cgal.org/


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

Attachment: debug-build-logs.7z
Description: Binary data