there!
I'd like to execute example program, Surface_reconstruction_points_3.
I think the program needs additionally 3rd library, MPFI.
So I downloaded the library from http://mpfi.gforge.inria.fr/.
And I unzipped it at proper folder and linked it to the system path.
After configurating the example program using cmake-gui,
I found some error message, 'Could NOT find MPFI (missing: MPFI_LIBRARIES)'.
How can I install MPFI library in Window using visual studio 2008?
Since MPFI is a GNU library, it is completely supported on Windows.
CGAL provides this third-party libraries inside its installation, but Windows has its own replacement.
I installed this correctly with Visual Studio, but you need to uncheck those third-party libraries so CGAL won't mess with the own windows replacements.
Maybe doing this kind of installation isn't working well for all the sample codes inside the installation, but it works fine for development. I used CGAL without those third-libraries for Voronoi and 2D and 3D triangulation and it works fine.
For a clean installation, delete all you installed previously, make sure the new installation isn't messing with the bad previous installation.
EDIT:
About not using those optional libraries for Windows, I just received a similar mail through the CGAL mailing list and these could be the steps for newer versions of CGAL (>4.2):
You have to comment 3 lines in the CMake machinery:
In CGAL-4.1/CMakeList.txt you have to comment:
#list (INSERT CGAL_ESSENTIAL_3RD_PARTY_LIBRARIES 0 GMP MPFR)
#hide_variable(CGAL_ESSENTIAL_3RD_PARTY_LIBRARIES)
In CGAL-4.1/cmake/modules/UseCGAL.cmake you have to comment:
#use_essential_libs()
On the other hand, you can search on internet for precompiled versions of MPFI. For instance, you can find precompiled GMP, MPFR and MPFI for Windows on http://vegas.loria.fr/rs/ .
Related
I want to use GCG's branch-and-price frame to solve a MIP which is similar to Binpacking problem. So I download the SCIPOptSuite-6.0.0-win64-VS15.exe and install it in Windows 7 and then install the Visual C++ Redistributable Packages which is required. Also I install the Cmake in Windows 7. But I do know how to do next after failed trying the instructions in the website https://scip.zib.de/doc-6.0.0/html/CMAKE.php (Installation information using CMake (recommended for new users)). I do not know where to start to compile. I even do not know whether the installation succeeds or not.
If you want to compile the code, you need to download the source package not the precompiled ones, as they don't include the source files.
As far as I know, GCG is not available in the precompiled packages, unfortunately.
I'm attempting to build TensorFlow's C++ library for Windows XP. While I've been able to build and use it on Windows 10, 32-bit XP isn't working. The background: I'm working on a COM module that calls fuctions from tensorflow.dll. My build environment:
Visual Studio 2017 15.7
CMake 3.11.1
TensorFlow 1.8
Windows 10
The sequence I use to build tensorflow.dll is:
Open "x64_x86 Cross Tools Command Prompt for VS 2017"
Try to force the use of functions availablbe in Win XP: set CXXFLAGS=/D_WINVER=0x0501 /D_WIN32_WINNT=0x0501
Add Git to path: set PATH=%PATH%;C:\Program Files (x86)\Git\bin
Fix CMake file for converting *.proto files to *.pb.h files as described here.
Configure CMake: cmake .. -A Win32 -T v141_xp,host=x64 -DCMAKE_SYSTEM_VERSION=7.0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=C:\Users\williams\AppData\Local\Continuum\Anaconda3\envs\tensorflow\python.exe -Dtensorflow_BUILD_SHARED_LIB=ON -Dtensorflow_BUILD_PYTHON_BINDINGS=OFF -Dtensorflow_WIN_CPU_SIMD_OPTIONS="/arch:IA32"
Build: cmake --build . --target tensorflow --config Release -- /fileLogger /m:1 /p:CL_MPCount=1
The last step also involves some manual labour as the build process doesn't copy .lib files from the 3rd part dependencies to where they are needed. For whatever reason, a bunch of INSTALL projects never get run so I had to do that manually each time the build would fail while looking for a missing lib file. Once that was done, the build completed successfully.
Next I copy my COM module (a DLL) and the TensorFlow DLL over to a Windows XP virtual machine for testing and try to register the COM module, but get an error LoadLibrary("MyDLL.dll") - The specified procedure could not be found. I don't know what procedure it is looking for, so the best I can offer is that Dependency Walker highlights WS2_32.DLL and tells me it can't find inet_ntop and inet_pton.
Any suggestions on how to build TensorFlow so that it doesn't use these two functions?
P.S. suggestions of "Stop using XP, its old and no longer supported" don't help here. Upgrading to Windows 10 is an absolute last resort because of the disruption it would cause at the facility where this software will be tested.
Edit 1:
These two functions inet_pton and inet_ntop were only used in one file that forms part of Google Cloud Storage support in TensorFlow. The build process generated a tensorflow_static.lib in addition to tensorflow.dll. Linking against the static version and adding a few dependencies that aren't included in tensorflow_static.lib got rid of the code using inet_* functions.
My COM module still isn't working on Windows XP though because the file tensorflow\core\platform\windows\env.cc uses functions like CloseThreadpoolWork, submit SubmitThreadpoolWork, etc. that were only introduced in Windows Vista. It looks like I'll have to replace them with something else, as I don't see an alternative implementation in TensorFlow.
Additionally, I found that tensorflow\contrib\cmake\CMakeLists.txt forces _WIN32_WINNT=0x0A00 and that CXXFLAGS is the wrong environment variable to use. Changing it to CMAKE_CXX_FLAGS at least gets my macro definitions included, FWIW.
It is almost impossible to port tensorflow to windows xp, because:
TF's platform depedent code requires some Windows APIs later than winxp such as Thread Pool API. This would possibly bypassed by using third party thread pool libs.
The nsync, protobuf and eigen, which are core parts of TF, use C++11 thread_local, which makes them unable to run-time load as dll, see https://learn.microsoft.com/en-us/cpp/parallel/thread-local-storage-tls?view=vs-2017 for details. This later feature can theoretically be replaced by old windows TLS API, which requires many modifications on TF's core framework.
Anyway, if you really need the xp support, good luck with that.
In the end I gave up on this as simply being impossible. Even replacing the thread pool functions with something from Boost didn't help. If someone else manages to get this working, I'll gladly accept that as the answer, but so far this looks impossible.
Trying to build PCL 1.8 using VTK 7.0.0. Target is Visual Studio 2015.
Using the VTK OpenGL2 backend I got errors similar to those reported here and here which indicate OpenGL2 is not supported for PCL yet.
However, using the original VTK OpenGL backend I get different errors:
The list of VTK libraries PCL projects link against includes libraries whose names suggest both OpenGL and OpenGL2, even though VTK is only configured with one or the other backend. For example, "vtkDomainsChemistryOpenGL2.lib" (when VTK backend is OpenGL).
"vtkDomainsChemistryOpenGL2.lib" does not exist, causing a linker error. However, a library called "vtkDomainsChemistryOpenGL2-7.0.lib" exists, so it appears a version suffix is added when VTK is built, but is not added when CMake generates the list of libraries to link PCL projects with.
vtkVertexBufferObject.cxx(104): error C2039: 'GetExtensionManager': is not a member of 'vtkOpenGLRenderWindow'. Class vtkOpenGLRenderWindow is suspiciously tagged with VTKRENDERINGOPENGL2_EXPORT (again in an OpenGL build).
I don't know whether the problem lies in VTK or PCL. The CMake build system is completely opaque to me so I am getting nowhere with this.
Just following up to myself (again)...
The problem was that, because I had initially built the "INSTALL" project of VTK using the OpenGL2 backend, then changed the backend to OpenGL and built the "INSTALL" project of VTK again, both backends existed in the install folder. VTKConfig.cmake (which PCL uses to link with VTK) finds and links against all modules that it finds in the install folder, thus attempting to link against both incompatible backends.
The VTK build system does not detect that conflicting modules are already present when installing, and the "make clean" or "rebuild" options don't remove conflicting modules (VTK does not have an uninstaller). Deleting CMake caches, or creating a new clean build directory, is not sufficient to clear up this mess.
So the only solution was to manually find and delete the VTK install folder ("C:\Program Files (x86)\VTK", for the record) if you need to change the VTK backend.
I want to use KDL (Kinematics and Dynamics Library) in robot control box. But robot control box uses SCons as their build system while KDL uses CMake.
It turned out that the control box doesn't have CMake installed. Should I install CMake in the control box? Or write SCons file for compiling KDL?
====================================================
My question is ambiguous. Sorry for that. And unfortunately, I cannot show the link of Control Box, it's not public. Here is link of KDL installation manual.
http://www.orocos.org/kdl/installation-manual
Let me make it more clear.
Forget all of previous question above and all about Control box, KDL. Let's say that you want to use one library. But the library can be built using CMake according to installation manual. Your PC doesn't have CMake installed but it has SCons, and unfortunately you should not install CMake on your PC.
If you can only use SCons, what can you do?
I know this situation is not usual, I want to know your opinion.
To answer your initial question: Yes, you should always try to install CMake, if that is a build requirement for you library and if you need to build that library from the sources.
To answer your later question: Replacing or rewriting the build system scripts is a major effort and not advisable. In general there is no script to convert build-systems. Such script might help to make the manual transformation. If you have a look at LLVM's effort to replace Autotools by CMake or Boost replacing it's own build system by CMake, you find out it takes several people several years and still not everybody is satisfied.
Often you don't need to build the library yourself. Either there are already built packages from the project directly of from your distribution (Debian etc. packages) or third party packagers like Mac Ports or NuGet.
In your case KDL provides Debian/Ubuntu packages.
Additional KDL is part of ROS, which is experimental in Homebrew for OS X.
I have compiled shared libraries dynamically linked against libstdc++.so using GLIBCXX_3.4.11. I want to send my code to someone whose stdc++ library is only of version 3.4.10. Rather than ask him to update his library version (this is a software customer, so I can't assume they'll be willing or able to change system files) I would like to ship the appropriate version of libstdc++.so, placed in a lib folder with the directory location of my code. How do I get my own code to use the appropriate (later) version? I find that /etc/ld.so.conf includes the directory /lib64, where an offending older version of libstdc++.so resides. Setting LD_LIBRARY_PATH does not override this. This seems to deviate from the advertised behavior. Any idea why this is happening? How do I complete my rather simple task?
Thanks.
I understand that this question is old, but I found it while trying to sort out my own linking trouble which was similar. You will have to build your program against a version of libstdc++ which is compatible with your colleague's version of the library. The easiest solution, of course, is to link against his version of the library so he doesn't need to make special tweaks on his side to link your library.
To do this, you will want to install a version of GCC which can build binary compatible libraries so you can actually link against his version of libstdc++. GLIBCXX_3.4.11 is from gcc-4.4 and later, so you will need gcc-4.3. Build your program using this and you should be in good shape.
You can consult the following page for a list of library ABI compatabilities:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
You could also build an rpm/deb which requires the version of libstdc++ you already have and if it's not available, refuse to install. This gives you a bit of an interface which gives him a promise that if his system is setup with the correct dependencies, he can use your library. In that sense, it's like a loose SLA for your library in what you do and don't support.
Hope that helps!