Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[draco] Can't link drakodec.lib with target_link_libraries, usage file missing #15527

Closed
MrROBUST opened this issue Jan 8, 2021 · 7 comments · Fixed by #27145
Closed

[draco] Can't link drakodec.lib with target_link_libraries, usage file missing #15527

MrROBUST opened this issue Jan 8, 2021 · 7 comments · Fixed by #27145
Assignees
Labels
category:port-bug The issue is with a library, which is something the port should already support category:port-update The issue is with a library, which is requesting update new revision

Comments

@MrROBUST
Copy link

MrROBUST commented Jan 8, 2021

Hello, after installing this library in vcpkg, it doesn't show how to use it.

I am trying to use the [draco] decoding support of the [tinygltf] library with this simple program example (main.cpp):

#include <nlohmann\json.hpp>

#define TINYGLTF_NO_STB_IMAGE
#define TINYGLTF_NO_STB_IMAGE_WRITE
#define TINYGLTF_IMPLEMENTATION
#define TINYGLTF_NO_INCLUDE_JSON
#define TINYGLTF_ENABLE_DRACO
#include <tiny_gltf.h>

int main()
{
  using namespace tinygltf;

  Model model;
  TinyGLTF loader;
  std::string err;
  std::string warn;

  if (!loader.LoadBinaryFromFile(&model, &err, &warn, "models/viking_room.glb"))
  {
    throw std::runtime_error(warn + "\n" + err);
  }

  return EXIT_SUCCESS;
}

CMakeLists.txt

cmake_minimum_required (VERSION 3.8)

project(TinyGltfDraco)

add_executable(TinyGltfDraco main.cpp)

set_target_properties(TinyGltfDraco
PROPERTIES
  CXX_STANDARD 17
  CXX_EXTENSIONS OFF
)

find_package(nlohmann_json CONFIG REQUIRED)
target_link_libraries(TinyGltfDraco PRIVATE nlohmann_json nlohmann_json::nlohmann_json)

find_path(TINYGLTF_INCLUDE_DIRS "tiny_gltf.h")
target_include_directories(TinyGltfDraco PRIVATE ${TINYGLTF_INCLUDE_DIRS})

The project is built by Cmake using the vcpkg toolkit. Building with the Visual Studio 2019 compilers generates some linkage errors:

[build] main.cpp
[build] main.obj : error LNK2019: unresolved external symbol "public: __cdecl draco::Options::Options(void)" (??0Options@draco@@qeaa@XZ) referenced in function "public: __cdecl draco::DracoOptions::DracoOptions(void)" (??0?$DracoOptions@W4Type@GeometryAttribute@draco@@@draco@@qeaa@XZ) [%path%\build\TinyGltfDraco.vcxproj]

It looks like Draco header files can be found automatically with no additions to CMakeLists, but dracodec.lib or draco.lib is not passed to the linker.

If I add these lines to CMakeLists:

find_package(Draco CONFIG REQUIRED)
target_link_libraries(TinyGltfDraco PRIVATE draco)

I got that error:

[build] LINK : fatal error LNK1104: cannot open file 'draco.lib' [%path%\build\TinyGltfDraco.vcxproj]

But something like this works (for a debug build):

find_package(Draco CONFIG REQUIRED)
target_link_libraries(TinyGltfDraco PRIVATE "${draco_LIBRARY_DIR}/../debug/lib/dracodec.lib")

I am wondering if I am doing something wrong or the port is missing some exports?

Additional context:
Draco's github page says we need to link the draco_dec (https://github.com/google/draco#c-decoder-api) but it's probably a typo (https://stackoverflow.com/questions/62313136/how-to-include-the-draco-dec-library). I have both draco.lib and dracodec.lib working so I'm not sure what should be linked by default. Should these be separate targets, like: target_link_libraries(TinyGltfDraco PRIVATE draco::draco) or target_link_libraries(TinyGltfDraco PRIVATE draco::dracodec)?

@NancyLi1013 NancyLi1013 added the category:port-bug The issue is with a library, which is something the port should already support label Jan 11, 2021
@NancyLi1013
Copy link
Contributor

NancyLi1013 commented Jan 14, 2021

Hi @MrROBUST

Thanks for posting this issue.

Seems there are some problems when using find_package() in draco. I will investigate and try to fix this later.

@NancyLi1013 NancyLi1013 added category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist category:port-bug The issue is with a library, which is something the port should already support and removed category:port-bug The issue is with a library, which is something the port should already support labels Jan 14, 2021
@JackBoosY
Copy link
Contributor

I think draco expoted DracoConfig.cmake is incomplete. It only contains difficult macros.

@JackBoosY JackBoosY removed the category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist label Jan 21, 2021
@NancyLi1013 NancyLi1013 added the depends:upstream-changes Waiting on a change to the upstream project label Jan 21, 2021
@PhoebeHui PhoebeHui assigned LilyWangLL and unassigned NancyLi1013 Nov 22, 2021
@LesleyLai
Copy link

Draco updated to 1.5.0 and reworked its find_package support in this PR. Probably that will fix the issue once vcpkg supports Draco 1.5.0

@JackBoosY
Copy link
Contributor

@LesleyLai No it wasn't.
The draco-config.cmake still can't be used in Windows.

@JackBoosY
Copy link
Contributor

I opened a PR to the upstream to fix this issue: google/draco#787
Let's see what happened.

@LesleyLai
Copy link

Thank you for doing this!

@LilyWangLL LilyWangLL removed the depends:upstream-changes Waiting on a change to the upstream project label Jul 29, 2022
@Tradias
Copy link
Contributor

Tradias commented Oct 8, 2022

Since draco 1.5.3 there is now a proper dracoConfig.cmake + dracoTargets.cmake which support imported targets. The usage information is also helpful now:

 draco provides CMake targets:
 
     # this is heuristically generated, and may not be correct
     find_package(draco CONFIG REQUIRED)
     target_link_libraries(main PRIVATE draco::draco)

See #27145

@JackBoosY JackBoosY added the category:port-update The issue is with a library, which is requesting update new revision label Oct 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-bug The issue is with a library, which is something the port should already support category:port-update The issue is with a library, which is requesting update new revision
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants