CGAL users discussion list

[Jeffrey Bush <>]

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.

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

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.

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.

I am totally understanding of cross-platform development and deployment issues, particularly for libraries that must be end-user compilable. And I do feel for you. The libraries I have developed are all really small so don't run into nearly the number of issues that you have but there are still always issues.

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. 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).

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). 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).

Thank you for your calm and detailed response!

Jeff

On Thu, Jan 31, 2013 at 5:50 AM, Laurent Rineau (CGAL/GeometryFactory) <> wrote:

Le jeudi 31 janvier 2013 00:43:04 Jeffrey Bush a écrit :

> Thanks. However, just so you know, the CGAL installer installs to Program
> Files (x86) on Windows x64.

Well, I am both the release manager of CGAL, and the maintainer of the CGAL
Windows installer, and because of those two roles I know pretty well where is
the default path for CGAL sources in that installer.

Please open the cmake-gui.exe interface, you will see that the first two
fields in that the UI are "Where is the source code:" and "Where to build
binaries:". It seems that you have not even wondered why there are two
different paths. Even if you let the CGAL Windows installer install CGAL
sources in the default path (under %ProgramFiles%), you can anyway build
binaries in your user Documents directory (for example), using the second
field! Otherwise a non-admin Windows account would not be able to compile
anything from default-installed CGAL sources!

The Qt4 CMake macros defined by the CMake script FindQt4 have a bug that, if
the CMAKE_BINARY_DIR contains a parenthesis, they go completely wrong. I am
not completely sure but I think that is because of the parenthesis in the
string "Program Files (x86)". We, CGAL developers, cannot do anything about
that. Anyway, compiling under %ProgramFiles% is not recommended, for the
integrity of that directory, and we do not try to support that configuration.

> I ended up getting around it by building just the examples and demos I
> wanted. However in the process of building all of this I have identified
> more problems. The boost libraries are not added to the import list in the
> resulting project, only the include directories are added. Each project
> needs to have the boot libraries manually entered. The CMAKE GUI shows the
> boost libraries it will add, with all the right path information, however
> these don't end up in the resulting VS project.

Boost libraries, under Windows, and when the compiler and linker are the ones
of Visual Studio, use a mechanism named auto-linking. So do CGAL libraries, by
the way. There is no need to add them in the project files.

You might want to read the following to know more about that feature:

  http://www.boost.org/more/getting_started/windows.html#auto-linking

> Another note. When trying to get the AABB demo to work in VS the program
> generated cannot be run (cannot be started correct 0xC000007B - bad image)
> . It can't even be debugged. I have used Qt before on this computer and the
> QGLViewer demos I tried all worked. The AABB_examples all worked as well
> (they have no GUI though). I have tried changing many of the build
> parameters in the generated VS project to no avail.

Do you have a modified version of Windows? Or a nasty anti-virus? Or a broken
hard drive?

As far as I know, that error "0xC000007B - bad image" signal that the binary
is corrupted. That cannot be produced by any regular compilation process.

> It seems as though Windows / MSVS support should be listed as "partial"
> until all these issues can be worked out (an installer that places files in
> a place that other scripts which have bugs fail to use, not including the
> Boost libs even when CMAKE successfully detects them, unable to run a
> demo). Tomorrow I will try on a Linux machine and hopefully have more luck.

As for the default path for the CGAL Windows installer, I am open to
suggestions for a better one.

What I could do for sure is make CMake emit an educating error message when
users are trying to use a sub-directory of %ProgramFiles% as CMAKE_BINARY_DIR.

Be sure that the CGAL project, and particularly GeometryFactory, is concerned
about the support for Windows and MSVS. CGAL has many users under Windows,
even several users using the commercial license. Microsoft Windows is a
platform that is particularly unfriendly for C++ development, but we have
managed to support that platform fully, with minor caveats.

I have the impression that your problems are due to your environment or your
particular usage of CGAL. You should follow the steps in that page:

  https://www.cgal.org/windows_installation.html

and see if you still have issues after that.


I hope that my indications will help you to find out what got wrong.

> Also, you give no help in the documentation on how to create a new program
> that uses CGAL on a Windows machine.

I agree with you on that part. The CGAL Installation manual does not say much
about *using* CGAL libraries, but only about *building* them. There should be
an extra section about that topic in the CGAL manuals.

> Everything depends on running the
> shell script cgal_create_CMakeLists which cannot be done on Windows.

Internal to CGAL, yes, everything depends on CMake, and that script
'cgal_create_CMakeLists' helps to write "CMakeLists.txt" files. But hopefully
CGAL is just like other libraries. The only difference is the use of auto-
linking.

On Windows, you just have to:
  - add the /path/to/CGAL-4.1/include directory in the INCLUDE path,
  - add the /path/to/your/CGAL/build/dir/lib directory in the path to search
for libs,
  - add the /path/to/your/CGAL/build/dir/bin in your PATH environment
variable.

--
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