Linking from C program on Mac

[OttoHatt]

Compiling a C program w/ cc linking nicegraf-mtl gives a number of linker errors:

ld: Undefined symbols:
  std::logic_error::logic_error(char const*), referenced from:
      std::length_error::length_error[abi:v160006](char const*) in libnicegraf-mtl.a[2](impl.mm.o)
  std::length_error::~length_error(), referenced from:
      std::__1::__throw_length_error[abi:v160006](char const*) in libnicegraf-mtl.a[2](impl.mm.o)
  std::bad_optional_access::~bad_optional_access(), referenced from:
      std::__1::__throw_bad_optional_access[abi:v160006]() in libnicegraf-mtl.a[2](impl.mm.o)
  std::bad_array_new_length::bad_array_new_length(), referenced from:
      std::__throw_bad_array_new_length[abi:v160006]() in libnicegraf-mtl.a[2](impl.mm.o)
  std::bad_array_new_length::~bad_array_new_length(), referenced from:
      std::__throw_bad_array_new_length[abi:v160006]() in libnicegraf-mtl.a[2](impl.mm.o)
  std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__init(char const*, unsigned long), referenced from:
      std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string[abi:v160006](char const*, unsigned long) in libnicegraf-mtl.a[2](impl.mm.o)
      std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string[abi:v160006]<std::nullptr_t>(char const*) in libnicegraf-mtl.a[2](impl.mm.o)
  std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::assign(char const*), referenced from:
      std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::operator=[abi:v160006](char const*) in libnicegraf-mtl.a[2](impl.mm.o)
  std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::~basic_string(), referenced from:
      _ngf_create_shader_stage in libnicegraf-mtl.a[2](impl.mm.o)
      _ngf_create_shader_stage in libnicegraf-mtl.a[2](impl.mm.o)
      ngf_shader_stage_t::~ngf_shader_stage_t() in libnicegraf-mtl.a[2](impl.mm.o)
      ngf_shader_stage_t::~ngf_shader_stage_t() in libnicegraf-mtl.a[2](impl.mm.o)
...etc

I can cut down on these by disabling exceptions. What's left is related to basic_string. But I can fix this by linking the c++ lib in my consuming application. Is that the intended solution?

[nicebyte]

try adding the -lstdc++ to the list of arguments passed to cc. nicegraf metal backend is c++ and likely to remain so (we're trying to escape objective-c). This means a dependency on the c++ runtime, even if we didn't use stl at all. cc doesn't link against libstdc++ by default which is why you got these errors.

[OttoHatt]

Linking stdc++ (or c++ works). Should this be a public dependency in the CMake file?

Also, I didn't realise there was a C++ duplicate of the metal backend! Is it at feature parity / preferable to use over the obj-c one?

[nicebyte]

Linking stdc++ (or c++ works). Should this be a public dependency in the CMake file?

Probably, yes. All code that currently uses nicegraf is C++ so we didn't run into that issue previously.

Also, I didn't realise there was a C++ duplicate of the metal backend! Is it at feature parity / preferable to use over the obj-c one?

There are no more major TODOs there, however it's not used in "production" yet. You'd be the first client outside of nicegraf samples to use it. It should eventually replace the legacy implementation and the replacement should be completely transparent to the clients, so I recommend sticking with the default implementation.

[OttoHatt]

I'm curious as to what your production use case for this library is? I'm using it for a game engine, though the apparent lack of bindless & indirect may prove it difficult to scale. Do those features align with your goals at all?

[nicebyte]

It is currently being used for a game engine as well. Indirect draw support is planned at some point in the near future (there is a ticket tracking it). Bindless is something I want to support as well, though it is not likely to happen soon. Neither of these have been a limiting factor so far.