claudec as requested here is at least some information regarding my efforts.
On my
stable/13 machine, I managed to get
libtorch.so to build successfully using the following configuration:
Code:
cmake \
-B build \
-DBUILD_SHARED_LIBS:BOOL=ON \
-DBUILD_BINARY:BOOL=ON \
-DBUILD_CAFFE2=ON \
-DCMAKE_BUILD_TYPE:STRING=Release \
-DBUILD_PYTHON=OFF \
-DBUILD_TEST=OFF \
-DONNX_ML=OFF \
-DUSE_OPENCV=ON \
-DUSE_CUDA=OFF \
-DUSE_CUDNN=OFF \
-DUSE_BREAKPAD=OFF \
-DUSE_FBGEMM=OFF \
-DUSE_KINETO=OFF \
-DBUILD_CUSTOM_PROTOBUF=OFF \
\
-DCMAKE_CXX_FLAGS="-Wno-error=bitwise-instead-of-logical -Wno-error=unused-but-set-variable -Wno-error=unused-parameter -Wno-error=sign-compare -pthread"
As usual, select your compiler(s) and Generator as needed. You most likely also want to use a compiler cache for this one because it's 1'700 files of beefy stuff. Took quite a while to build.
This shouldn't matter but I'd rather state it upfront: I used
devel/llvm14 rather than clang from base (for unrelated reasons).
The only quirky part in that configuration is the manual setting of the C++ flags. This is due to this "bug":
https://github.com/pytorch/FBGEMM/issues/957
This should most likely not be the final configuration tho. I'm especially eyeballing
-pthread as this should definitely be handled by CMake itself but as I stated initially I was only spending an hour or two on trying to get this to build.
You definitely want to use the latest `master` branch too. The latest release came with a few more issues that have been addressed in the meantime. On that note,
USE_BREAKPAD doesn't seem to be a CMake option anymore in the current master but as stated prior, I did not invest the time needed to get this to build "properly" yet.
Other caveats apply as usual such as the fact that CUDA will most likely not work on FreeBSD (as per my understanding). I also had some issues regarding ONNX but decided to just disable it until I have a working system.
As far as dependencies go: The only one I had to install was
devel/py-typing-extensions. I assume everything else was already present on my system but dependencies should be comparably easy to handle (especially in case of python packages).
After successfully building `libtorch.so` you'll most likely run into some compiler & runtime errors when actually trying to link & load it. This will almost definitely also propagate to the python wrappers/bindings/interfaces but those are of no interest to me.
github.com
).