Undefined ref to 'function<void ()()>::operator()() const' when called from free function defined in cc file.

Chris Fairles chris.fairles@gmail.com
Fri Aug 29 19:29:00 GMT 2008


I was working on call_once and got this odd error:

bin/ld: lib64/libstdc++.so: undefined reference to 'std::function<void
()()>::operator()() const'
bin/ld: lib64/libstdc++.so: undefined reference to 'std::function<void
()()>::function(std::function<void ()()> const&)'
collect2: ld returned 1 exit status

In <mutex> I have the following (in std namespace):

extern function<void()> __once_proxy_object;
extern unique_lock<mutex> __once_proxy_lock;
extern "C" void __once_proxy();

template<typename _Callable, typename... _Args>
  void
  call_once(once_flag& __once, _Callable __f, _Args&&... __args)
  {
    __once_proxy_lock.lock();
    __once_proxy_object = bind(__f, __args...);

    int __e = __gthread_once(&(__once._M_once), &__once_proxy);

    if(__once_proxy_lock)
      __once_proxy_lock.unlock();

    if (__e)
      __throw_system_error(__e);
  }

In mutex.cc I have (in std namespace):

mutex __once_proxy_mutex;
unique_lock<mutex> __once_proxy_lock(__once_proxy_mutex, defer_lock);
function<void()> __once_proxy_object;

extern "C"
{
  void __once_proxy()
  {
    function<void()> __f(__once_proxy_object);
    __once_proxy_lock.unlock();

    __f();
  }
}

Disregarding the actual run-time context here, semantically what could
be causing this? extern "C" has nothing to do with it it seems. After
commenting out the construction of __f and the call __f(), the errors
disappear. I've also added:

_ZSt17__once_proxy_lock;
_ZSt18__once_proxy_mutex;
_ZSt19__once_proxy_object;
__once_proxy;

to gnu.ver as per usual.

"nm mutex.o" shows:
U _ZNKSt8functionIFvvEEclEv
U _ZNSt8functionIFvvEEC1ERKS1_
W _ZNSt8functionIFvvEED1Ev

So there's 2 undefined symbols but why? <functional> is being included
in <mutex>. I even tried including it right in mutex.cc. std::function
does have a cctor and operator()() defined right in the header...

Am I doing something obviously wrong here? I can't reproduce in any
small test case outside of libstdc++. If more context is needed I can
post the whole patch but its a work-in-progress so hopefully the above
is enough to go on.


Chris



More information about the Libstdc++ mailing list