[filesystem in 1.34.0]link error: unresolved status_api
Hi everyone: If calling convention is changed to __stdcall in vc8, there will be a 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 &)" ... Here's my test code: #include <boost/filesystem.hpp> int main() { boost::filesystem::path p("a.txt"); boost::filesystem::exists(p); return 0; } Should status_api() be restricted to __cdecl explicitly?
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
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.
participants (2)
-
Minmin Gong -
Ulrich Eckhardt