I'm running Centos 7 and am trying to build hipSYCL (see here)
The issue is that hipSYCL needs to have cmake info from the LLVM build (via the LLVM_DIR cmake variable).
This is problematic for me because building LLVM requires a massive 35Gb for the libraries and exes. I don't have that much memory to spare.
I did find a build of llvm-toolset-8.0 online for Centos 7 and installed it, but to my surprise, that didn't seem to work with LLVM_DIR because there's no cmake files (since I didn't build it locally).
So, my question would be, is there a way to build hipSYCL using pre-built LLVM-clang?
If I'm missing or misunderstanding something, I'd appreciate any help.
LLVM publishes the necessary cmake files, and the binary OS packages I've seen include it, generally in a directory called /usr/lib/llvm*/lib/cmake and in a package called something like llvm-*-dev.
Related
I've been trying to build GCC 10.2 on my Intel MBP. As I've always done, I'm building from source and installing on /usr/local. Trouble is no matter what, the build fails on STAGE2 of bootstrapping. A careful search on all logs (including dependencies) could not point to a single fault. The only thing that stood out was the clang setup from Xcode Command Line Tools. When I run 'gcc -v' on a clean system (empty /usr/local), it outputs:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Trouble is that the target for --with-gxx-include-dir doesn't exist! There is no c++ subfolder, to begin with. Although there is one from the --prefix tree, instead of 4.2.1, there is just a v1 subfolder.
It would appear that there is something terribly wrong with Xcode Command Line Tools. But I can't be sure that this is the cause of my own troubles.
Please, don't answer this post pointing me to a package manager... there's a reason I abandoned those years ago. Also, it would be off-topic to the issue at hand.
I've finally managed to isolate the issue. GCC 10.2 depends on GMP, MPFR, MPC, and ISL libraries. I had them manually installed with the latest version available and fine tuned to my system. I didn't explore if it was a version conflict, or a fine tuning issue, but that broke the build. The solution was to let the script 'contrib/download_prerequisites' (within gcc tree) download the appropriate versions that were built along with GCC.
I also found out that the '--with-gxx-include-dir' target is a non-issue. It isn't supposed to point anywhere in my system. It is a reference to the system that built the "gcc" provided by Xcode Command Line Tools.
A couple of days ago I have started to migrate my CMake-based C++ library project from Travis CI to GitHub Actions. I immediately ran into trouble with the windows-latest runner (link to runner specs). After many wasted hours I tracked down the issue to the Windows SDK that CMake selects when it generates the build system.
On a local VM where I tried to replicate the runner environment CMake always selects the SDK version 10.0.18362.0, because no other SDK is installed on that system. On the runner system, though, there seem to be several SDKs installed (cf. the runner specs), and CMake by default selects SDK version 10.0.17763.0.
The actual problem: With 10.0.17763.0 selected, as soon as the first file is being compiled the compiler starts spewing out C5105 warnings like the following (line breaks added by me for better readability):
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\corecrt_search.h(188,5):
warning C5105: macro expansion producing 'defined' has undefined behavior
[D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\stdlib.h(79,5):
warning C5105: macro expansion producing 'defined' has undefined behavior
[D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]
[...]
Eventually there are also errors which cause the build to fail. The first of these errors is this:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(487,17):
error C2059: syntax error: '/'
[D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]
When I force CMake to use a different SDK, by setting CMAKE_SYSTEM_VERSION to 10.0.18362.0, all problems go away and the build works fine.
Before I go down that road of forcing CMake to do something it doesn't want to do, I wanted to ask for advice if someone can recommend a better approach?
Also of interest would be if someone could explain what's actually going on here? How is it possible that MSVC has problems parsing Microsoft's own system header files when using one SDK version, and no problem at all when using another SDK version? Link to a build log in case someone is interested, but this might go away soon when I delete the branch.
In the meantime I managed to reproduce the problem on my local VM by installing the component "Windows 10 SDK (10.0.17763.0)" in the Visual Studio Installer. On the VM CMake still defaults to 10.0.18362.0, but when I force it to use 10.0.17763.0 like this
cd build
cmake -DCMAKE_SYSTEM_VERSION="10.0.17763.0" ..
then I get the same build failure as on the Github Actions runner. At least I can now say that it's not the Github Actions runner that is at fault.
On the other hand I also can't see how my project should be the culprit. I certainly don't do anything special that should make the project build with one Windows SDK, but not with the other.
Lacking the time (and the will) to further investigate the issue, for the moment I decided to follow the path of least resistance and am now building with these lines in the project's build.yml:
cd build
cmake -DCMAKE_SYSTEM_VERSION="10.0.18362.0" ..
cmake --build . --config Release
I'm trying to get the Dart SDK on a Pi Zero W.
When I download the SDK archive, extract it, and put it in the /usr/lib folder manually, I get segmentation faults when I try to run any of the command line tools. I reflashed the memory card (32GB, so plenty large) from scratch from an x64 machine and pre-loaded the SDK as well to help ensure that there wasn't any funky Pi file corruption and got the same result.
Though I was sure it wouldn't work, I loaded the ARM7 version of the SDK, and got executable file format incompatibility errors that were not surprising.
I downloaded the .deb package, and got a warning that the file was not meant for my Pi and that I might break things, so I didn't try to install it.
I used the apt-get instructions from the Dart website and that failed with the error "E: Unable to locate package dart" which seems to indicate that I had the incorrect name for the package (note: I copied and pasted it directly from the Dart website). I tried to look through the repository contents, and assuming that I looked at the correct file, there were not any Dart entries in it, so the error is not surprising.
My Linux competence is suspect, so I could use any ideas. I'd prefer not to build the SDK from scratch as, in my experience, open source build instructions almost always assume that the user needs to know/do something that is not explicitly listed in the instructions, so that tends to be a 2-hour effort that ultimately fails (pretty sure I'm not the only one who's had that experience).
Thoughts, anyone?
That is not going to work. Your problem is that "Pi Zero W" is a "1GHz single-core ARMv6 CPU (BCM2835)" CPU which means it can only execute programs for the ARMv6 architecture or lower.
Dart does have a minimum requirement for ARMv7 since they removed support for ARMv6 early this year: https://github.com/dart-lang/sdk/issues/42069
The support was never that great for ARMv6 (I did have an old Raspberry Pi) and programs was running really slow with missing support for FFI. So my recommendation is to get a board which supports ARMv7 or ARMv8 (ARM64) which works really great.
I'm interested in incorporating TensorFlow into a C++ server application built in Visual Studio on Windows 10 and I need to know if that's possible.
Google recently announced Windows support for TensorFlow: https://developers.googleblog.com/2016/11/tensorflow-0-12-adds-support-for-windows.html
but from what I can tell this is just a pip install for the more commonly used Python package, and to use the C++ API you need to build the repo from source yourself: How to build and use Google TensorFlow C++ api
I tried building the project myself using bazel, but ran into issues trying to configure the build.
Is there a way to get TensorFlow C++ to work in native Windows (not using Docker or the new Windows 10 Linux subsystem, as I've seen others post about)?
Thanks,
Ian
It is certainly possible to use TensorFlow's C++ API on Windows, but it is not currently very easy. Right now, the easiest way to build against the C++ API on Windows would be to build with CMake, and adapt the CMake rules for the tf_tutorials_example_trainer project (see the source code here). Building with CMake will give you a Visual Studio project in which you can implement your C++ TensorFlow program.
Note that the tf_tutorials_example_trainer project builds a Console Application that statically links all of the TensorFlow runtime into your program. At present we have not written the necessary rules to create a reusable TensorFlow DLL, although this would be technially possible: for example, the Python extension is a DLL that includes the runtime, but does not export the necessary symbols to use TensorFlow's C or C++ APIs directly.
There is a detailed guide by Joe Antognini and a similar TensorFlow ReadMe at GitHub explaining the building of TensorFlow source via CMake. You also need to have SWIG installed on your machine which allows connecting C/C++ source with the Python scripting language. I did use Visual CMAKE (cmake-gui) with the screen capture shown below.
In the CMake configuration, I used Visual Studio 15 2017 compiler. Once this stage successfully completes, you can click on the Generate button to go ahead with the actual build process.
However, on Visual Studio 2015, when I attempted building via the "ALL_BUILD" project, the setup gave me "build tools for v141 cannot be found" error. This did not go away even when I attempted to retarget my solution. Finally, the solution got built successfully with Visual Studio 2017. You also need to manually set the SWIG_EXECUTABLE path in CMake before it successfully configures.
As indicated in the Antognini link, for me the build took about half an hour on a 16GB RAM, Core i7 machine. Once done, you might want to validate your build by attempting to run the tf_tutorials_example_trainer.exe file.
Hope this helps!
For our latest work on building TensorFlow C++ API on Windows, please look at this github page. This works on Windows 10, currently without CUDA support (only CPU).
PS:
Only the bazel build method works, because CMake is not supported and not maintained anymore, resulting in CMake configuration errors.
I had to use a downgraded version of my Visual Studio 2017 (from 15.7.5 to 15.4) by adding "VC++ 2017 version 15.4 v14.11 toolset" through the installer (Individual Components tab).
The cmake command which worked for me was:
cmake .. -A x64 -DCMAKE_BUILD_TYPE=Release ^
-T "v141,version=14.11" ^
-DSWIG_EXECUTABLE="C:/Program Files/swigwin-3.0.12/swig.exe" ^
-DPYTHON_EXECUTABLE="C:/Program Files/Python/python.exe" ^
-DPYTHON_LIBRARIES="C:/Program Files/Python/libs/python27.lib" ^
-Dtensorflow_ENABLE_GPU=ON ^
-DCUDNN_HOME="C:/Program Files/cudnn-9.2-windows10-x64-v7.1/cuda" ^
-DCUDA_TOOLKIT_ROOT_DIR="C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.0"
After the build, open tensorflow.sln in Visual Studio and build ALL_BUILD.
If you want to enable GPU computation, do check your Graphics Card here (Compute Capability > 3.5). Do remember to install all the packages (Cuda Toolkit 9.0, cuDNN, Python 3.7, SWIG, Git, CMake...) and add the paths to the environment variable in the beginning.
I made a README detailing how to I built the Tensorflow dll and .lib file for the C++ API on Windows with GPU support building from source with Bazel. Tensorflow version 1.14
The tutorial is step by step and starts at the very beginning, so you may have to scroll down past steps you have already done, like checking your hardware, installing Bazel etc.
Here is the url: https://github.com/sitting-duck/stuff/tree/master/ai/tensorflow/build_tensorflow_1.14_source_for_Windows
Probably you will want to scroll all the way down to this part:
https://github.com/sitting-duck/stuff/tree/master/ai/tensorflow/build_tensorflow_1.14_source_for_Windows#step-7-build-the-dll
It shows how to pass command to create .lib and .dll.
Then to test your .lib you should link it into your c++ project,
Then it will show you how to identify and fix the missing symbols using the TF_EXPORT macro
I am actively working on making this tutorial better so feel free to leave comments on this answer if you are having problems.
I'm attempting to use OpenCV for Windows as supplied by opencv.org in a project I'm building with JetBrains' CLion IDE. I've installed the opencv library and configured CLion (set(OpenCV_DIR) to reference the build directory under it, but CMake issues the warning:
Found OpenCV Windows Pack but it has no binaries compatible with your configuration.
You should manually point CMake variable OpenCV_DIR to your build of OpenCV library.
I've tried some of the older distributions from opencv.org with the same results. It appears CMake is locating the OpenCV libraries, but doesn't want to use them. Why, and how do I get the OpenCV libraries to work under CLion?
The short answer is, you will probably need to build OpenCV from source in order to use it with CLion. But given the number and range of partially answered and unanswered questions here* and elsewhere on using JetBrains' CLion IDE with the OpenCV library, I think an overview is needed (my notes are from CLion 2016.3 and OpenCV 3.1, YMMV):
Though not produced by JetBrains, CMake is very central to CLion's operation. Understanding CMake therefore helps greatly in diagnosing CLion build problems. In particular CMake maintains a disk "cache" of settings which you may need to clear to incorporate changes to your environment (Tools->CMake->Reset Cache and Reload Project).
To make use of OpenCV in your build you must specify it in your project's CMakeLists.txt file. You request that CMake locate your OpenCV location and link it to your TARGET. An example of a sequence of commands from CMakeLists.txt for an executable named mushroom follows:
add_executable(mushroom ${SOURCE_FILES})
FIND_PACKAGE(OpenCV REQUIRED)
TARGET_LINK_LIBRARIES(mushroom ${OpenCV_LIBS})
(For more on FIND_PACKAGE, see CMake:How To Find Libraries.)
FIND_PACKAGE for package XXX works either by way of FindXXX.cmake files located at CMake's Modules directory, or by consulting environment variable XXXX_DIR. On my system, no FindOpenCV.cmake file was present, so I relied on the OpenCV_DIR environment variable instead. This must be set, not to the root of your OpenCV installation, but to the build folder beneath it. I used an entry in CMakeLists.txt to set this variable, e.g.:
set(OpenCV_DIR C:/Users/myacct/AppData/Local/opencv-3.0.0/build)
To link with OpenCV, CMake uses either FindOpenCV.cmake or OpenCV_DIR (see previous point above) to locate a file named OpenCVConfig.cmake. This file is generated by and ships with a particular build of OpenCV in order to document what components are present and where they are located.
Problems may occur when variable names used by OpenCVConfig.cmake conflict with those CLion has stored in its environment. In particular, if your OpenCV was built by Microsoft Visual C (MSVC), as is the Windows distribution from opencv.org, it won't work with CLion.
Because CLion's build toolchain (ControlAltS-toolchain) uses either MinGW or Cygwin, OpenCVConfig.cmake will search for OpenCV binaries under a subdirectory named mingw or cygwin and will find none because the binaries were built with MSVC (it will look in a directory like vc11 or vc12 instead). This probably means you will need to build OpenCV from source in order to use it with CLion.
Would reconfiguring OpenCVConfig.cmake to point to the MSVC binaries make this work? you may ask. Unfortunately the answer is still no, because libraries built with one compiler typically cannot be linked with another one.
OpenCVConfig.cmake or FindOpenCV.cmake likely contain diagnostic messages, but when CLion executes CMake for you, message(STATUS) calls are not displayed. To make them display, change them to message(WARNING) or message(FATAL_ERROR). But CLion 2016.3 EAP relieves this problem; see https://stackoverflow.com/a/39398373/5025060.
CLion does not indicate which .cmake script issued which diagnostics; don't assume they all come from the same script.
Hopefully this provides some general guidance on resolving CLion / CMake / OpenCV compatibility problems. Note that this does not cover compiler or linker issues; these will not appear until CMake completes its initial makefile build. Compiler or linker issues occur at a later stage and are controlled by include*(), link*() and other commands in CMakeLists.txt.
*Some related SO questions:
OpenCV Windows setup with CLion
OpenCV CLion (Cmake) linking issue - cmake reports a strange error
use OpenCV with Clion IDE on Windows
Compiling OpenCV on Windows with MinGW
Could not find module FindOpenCV.cmake ( Error in configuration process)
CMake: Of what use is find_package() if you need to specify CMAKE_MODULE_PATH anyway?