Move semantics between an application and shared library

[3hM2Nwbp]

Consider the following:

// Assume this is compiled to "SomeLibrary.so"
extern "C"
{
  std::vector<int>&& action()
  {
      return std::move((std::vector<int>()));
  }
}

// And this is an application that loads "SomeLibrary.so"
template<typename RET, typename... ARGS>
typename std::function<RET(ARGS...)> loadSymbol(void* handle, const std::string& symbol)
{
  typedef RET (*Signature)(ARGS...);
  // This smells funny...in a bad way...
  return std::function<RET(ARGS...)>((reinterpret_cast<Signature>(dlsym(handle, name.c_str()))));
}

int main()
{
  void* handle = dlopen("SomeLibrary.so", RTLD_LAZY);
  if(handle)
  {
    loadSymbol<std::vector<int>&&>(handle, "action"); // <-- Boom
  }
  //...
}

This crashes on the linux distribution that I'm working with. Is there something obvious that I'm doing wrong or is something more "linuxy" happening?

Thanks

[kbw]

It's possible that the shared lib and the app have different heaps, happens all the time with Windows DLLs.

The memory is allocated in the shared lib's heap and that heap address is released to the application's heap.

[3hM2Nwbp]

I think it is more of a stack problem. Dynamic memory (vector<T>*) works just fine but I would like to avoid pointers if at all possible...

[norm b]

FYI it works fine on Debian Sid after correcting the following:

main.cpp:16:43: error: too few arguments to function ‘void* dlopen(const char*, int)’
void* handle = dlopen("./somelibrary.so");

$ g++ -v
gcc version 4.8.2 (Debian 4.8.2-21)

$ldd --version
ldd (Debian EGLIBC 2.18-5) 2.18

[3hM2Nwbp]

Thanks for the info norm. That was a simple mistake on my part while creating a small scale example of the condition.

The code indeed fails on Linux Mint under clang 3.4. Perhaps I'll see if an update is available for clang.