Libtorch with new C++11 ABI?

C++
1

Hi!

I have, as many others, problems with linking my C++ code using libtorch with other libraries (eg. OpenCV). I understand that the problem is due to forced old C++11 ABI linkage. Is there a plan to release libtorch builds with new ABI?

I tried to build libtorch myself using build_libtorch.py, but the process is very cumbersome and I still got a lot of linkage problems afterwards (aka missing __fatbinwrap… etc.).

3 Likes
2

Examples

I think I meet the same problem, here is an example:

/* A.cpp */
#include <iostream>
#include <string>
using UString = std::u32string;
void foo(const UString &ustr) {
     std::cout << "hello" << '\n';
}
int main () {
    UString ustr = U"xxxx";
    foo(ustr);
}

# CMakeLists.txt for A.cpp
project(first_example)
set(CMAKE_CXX_STANDARD 17)
add_library(B B.cpp)
target_link_libraries(B)

Symbol of foo in libA.a is:

$ nm --demangle libA.a | grep foo
...
0000000000000000 T foo(std::__cxx11::basic_string<char32_t, std::char_traits<char32_t>, std::allocator<char32_t> > const&)

std::__cxx11::basic_string is a new version of std::basic_string, where the introduced namespace __cxx11 is designed for backwards compatibility. When libtorch is included, it forces the project to link to the old version of standard library.

/* B.cpp */
#include <iostream>
#include <string>
using UString = std::u32string;
void foo(const UString &ustr) {
    std::cout << "hello" << '\n';
}
int main () {
    UString ustr = U"xxxx";
    foo(ustr);
}

# CMakeLists.txt for B.cpp
project(first_example)
set(CMAKE_CXX_STANDARD 17)
find_package(Torch REQUIRED)
add_library(A A.cpp)
target_link_libraries(first "${TORCH_LIBRARIES}")

After building libB.a, the symbol of foo is:

$ nm --demangle libB.a | grep foo
...
0000000000000301 T foo(std::basic_string<char32_t, std::char_traits<char32_t>, std::allocator<char32_t> > const&)

If other libraries the project relied on are linked to std::__cxx11:: and the project is forced to link to old version, there will be tons of undefined reference errors. Is there any way to solve this problem with lower cost ?

Environment

Note

If there is anything wrong, please feel free to edit.

1 Like
3

Hey there,

can you try to build libtorch from source with Anaconda? The process is described here. Does this solve the problem?

4

I had build libtorch from source based on /tools/build_libtorch.py.
But, they are slower than official version.
Are you meet this issue?

5

You can use my Docker image to build libtorch C++ only files with MKL support.

Build the image and then use package.sh to create libtorch binary redistributable with similar structure as official nightly Torch builds.

1 Like
6

Thanks, this works for me ~

1 Like
7

I meet this issue too

8

We have a Github issue tracking this: https://github.com/pytorch/pytorch/issues/17492.

1 Like
9

We now have new ABI binaries for libtorch. They can be found on
http://pytorch.org, or at https://github.com/pytorch/pytorch/issues/17492#issuecomment-524692441.

1 Like
10

I have integrated the new ABI lib in my Docker file which also encapsulates the correct OpenCV version so that the notorious cv::imread() method works. I worked days and nights on attempting to compile libtorch + OpenCV from scratch with or without the -DCMAKE_CXX_FLAGS=-D_GLIBCXX_USE_CXX11_ABI=0 flag.

1 Like