I have a library that uses many dependencies managed by vcpkg. I have never had any issues until I recently added OpenImageIO.
On Windows 10 (MSVC 17.6) my library builds and links successfully, and then I am able to build an application and link my library to it.
On Ubuntu 20.04.6 (g++ 10.5.0, ld 2.34) my library builds and links successfully, but all applications fail to link against it with many errors stating an undefined reference to some boost library.
When I build my library as a static lib (on Ubuntu) it yields errors that look like the following:
/usr/bin/ld: ../../vcpkg_installed/x64-linux/debug/lib/libOpenImageIO_d.a(imageinput.cpp.o): in function `boost::thread_specific_ptr<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::~thread_specific_ptr()':
/mnt/c/Users/cgnam/source/repos/vira/out/ubuntu/vcpkg_installed/x64-linux/include/boost/thread/tss.hpp:61: undefined reference to `boost::detail::set_tss_data(void const*, void (*)(void (*)(void*), void*), void (*)(void*), void*, bool)'
Can be found at https://github.com/crgnam/oiio-linker-error
(Required vcpkg
on your computer):
To given more details without needing the repository the file structure looks like this:
vcpkg.json
CMakeLists.txt
myapp.cpp
mylib.cpp
mylib.hpp
vcpkg.json
:
{
"name": "vira",
"version-string": "0.8.0",
"dependencies": [
"openimageio"
],
"overrides": [
{
"name": "openimageio",
"version": "2.5.8.0#2"
}
],
"builtin-baseline": "352c108a6b6d698c09a8272d8e95fdce550ae408"
}
CMakeLists.txt
:
cmake_minimum_required(VERSION 3.19)
project(example LANGUAGES CXX VERSION 0.8.0)
set(CXX_STANDARD 20)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
include_directories(.)
# Build and link my library:
add_library(mylib STATIC mylib.cpp)
find_package(OpenImageIO CONFIG REQUIRED)
target_link_libraries(mylib PRIVATE OpenImageIO::OpenImageIO)
# Build and link Executable:
add_executable(myapp myapp.cpp)
target_link_libraries(myapp PRIVATE mylib)
mylib.hpp
:
#ifndef MYLIB_MYLIB_HPP
#define MYLIB_MYLIB_HPP
#include <string>
namespace mylib {
void getImageDimensions(const std::string& filepath);
};
#endif
mylib.cpp
:
#include "mylib.hpp"
#include <string>
#include <iostream>
#include <stdexcept>
#include "OpenImageIO/imageio.h"
#include "OpenImageIO/imagebuf.h"
namespace mylib {
void getImageDimensions(const std::string& filepath)
{
// Open the file:
auto inp = OIIO::ImageInput::open(filepath);
if (!inp) {
throw std::runtime_error("OpenImageIO could not open: " + filepath);
};
const OIIO::ImageSpec& spec = inp->spec();
int width = spec.width;
int height = spec.height;
int channels = spec.nchannels;
std::cout << width << " x " << height << " x " << channels << "\n";
};
};
myapp.cpp
:
#include <string>
#include "mylib.hpp"
int main(int argc, char* argv[])
{
if (argc == 2) {
const std::string& filepath = argv[1];
mylib::getImageDimensions(filepath);
return 0;
}
else {
return 1;
};
};
Build with:
mkdir build;
cd build;
cmake -DCMAKE_TOOLCHAIN_FILE=<path/to/vcpkg>/scripts/buildsystems/vcpkg.cmake ../
cmake --build .
Things I have already tried:
PUBLIC
instead of PRIVATE
(changing source/mylib/CMakeLists.txt
to use: target_link_libraries(mylib PUBLIC OpenImageIO::OpenImageIO)
)source/myapp/CMakeLists.txt
to use: target_link_libraries(myapp PRIVATE OpenImageIO::OpenImageIO mylib)
)So far, everything I try still successfully builds and links the library, but fails to link the library to my executable. (Though, everything works fine on Windows/MSVC)
If I install OpenImageIO using sudo apt install libopenimageio-dev
, and do NOT use vcpkg, and then change the source/mylib/CMakeLists.txt
to:
add_library(mylib STATIC mylib.cpp)
find_library(OIIO OpenImageIO)
target_link_libraries(mylib PRIVATE ${OIIO})
My application will successfully link to mylib
and runs fine (on Ubuntu).
Does this mean that there is something wrong with vcpkg port? Or am I misunderstanding something? Because my expectation (as with all of the other libraries that I use) is that this shouldn't be a problem (and indeed, it isn't with my other libraries such as TBB, cpsice, etc., or on Windows).
The newly added version 2.5.12.0#2 fixes the issue.