Re: [boost] [filesystem in 1.34.0]link error: unresolved status_api

From: Minmin Gong (gongminmin_at_[hidden])
Date: 2007-05-20 10:34:03

Ulrich Eckhardt wrote:
> On Saturday 19 May 2007 10:41:31 Minmin Gong wrote:
>> If calling convention is changed to __stdcall in vc8
> 
> You mean you changed the default calling convention? This is a recipe for 
> disaster, because it changes the interface of every function not explicitly 
> given a different calling convention. At the very least, it means you need to 
> recompile all of the filesystem lib with equal settings.
> 
>> link error like this: error LNK2019: unresolved external symbol "class
>> boost::filesystem::file_status __stdcall
>> boost::filesystem::detail::status_api(class
>> std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class
>> std::allocator<wchar_t> > const &,unsigned int &)" ...
> 
> There's another possibility though: Looking at operations.cpp, the wchar_t 
> version of that function is only compiled when BOOST_FILESYSTEM_NARROW_ONLY 
> is not defined. Why that would change with the default calling convention is 
> beyond me though.
> 
> Uli
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

My fault. The line 5 should be "boost::filesystem::wpath p(L"a.txt");" 
so it's not because of wchar_t.
Yes I changed the default calling convention in my app but not changed 
it in boost.filesystem. I just wonder if all the functions in 
filesystem's interface can be declared explicitly to __cdecl to prevent 
from this situation.