Re: Using Fortran Subroutines in C++
Olumide
I'm trying to compile and link the C++ program http://matrixprogramming.com/LAPACK/dgesv.cpp
with Visual studio (using a GotoBLAS library compiled in Cygwin). The
compilation works fine, but linking fails with the error message given
below.
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _fabs
referenced in function _main
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _DGESV
referenced in function _main
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _rand
referenced in function _main
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _srand
referenced in function _main
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _atoi
referenced in function _main
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _clock
referenced in function _main
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
___CxxFrameHandler
Demo_LAPACK.obj : error LNK2019: unresolved external symbol
___CxxFrameHandler referenced in function __ehhandler$_main
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
___CxxFrameHandler
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
___CxxFrameHandler
libcpmtd.lib(string.obj) : error LNK2019: unresolved external symbol
___CxxFrameHandler referenced in function $L12220
Demo_LAPACK.obj : error LNK2001: unresolved external symbol __fltused
Demo_LAPACK.obj : error LNK2019: unresolved external symbol
__RTC_CheckEsp referenced in function _main
Demo_LAPACK.obj : error LNK2019: unresolved external symbol
@_RTC_CheckStackVars@8 referenced in function _main
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
__except_list
libcpmtd.lib(xwctomb.obj) : error LNK2001: unresolved external symbol
__except_list
libcpmtd.lib(_tolower.obj) : error LNK2001: unresolved external symbol
__except_list
libcpmtd.lib(_toupper.obj) : error LNK2001: unresolved external symbol
__except_list
Demo_LAPACK.obj : error LNK2019: unresolved external symbol
__except_list referenced in function _main
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
__except_list
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
__except_list
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
__except_list
Demo_LAPACK.obj : error LNK2001: unresolved external symbol
__RTC_Shutdown
Demo_LAPACK.obj : error LNK2001: unresolved external symbol
__RTC_InitBase
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
__CxxThrowException@8
libcpmtd.lib(nomemory.obj) : error LNK2001: unresolved external symbol
__CxxThrowException@8
Demo_LAPACK.obj : error LNK2019: unresolved external symbol
__CxxThrowException@8 referenced in function __catch$??0?$vector@NV?
$allocator@N@std@@@std@@QAE@ABV01@@Z$0
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
__CxxThrowException@8
libcpmtd.lib(ios.obj) : error LNK2019: unresolved external symbol
__CxxThrowException@8 referenced in function "private: struct
std::ios_base::_Iosarray & __thiscall std::ios_base::_Findarr(int)" (?
_Findarr@ios_base@std@@AAEAAU_Iosarray@12@H@Z)
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
__CxxThrowException@8
libcpmtd.lib(nomemory.obj) : error LNK2001: unresolved external symbol
"public: __thiscall exception::exception(class exception const &)" (??
0exception@@QAE@ABV0@@Z)
Demo_LAPACK.obj : error LNK2001: unresolved external symbol "public:
__thiscall exception::exception(class exception const &)" (??
0exception@@QAE@ABV0@@Z)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
"public: __thiscall exception::exception(class exception const &)" (??
0exception@@QAE@ABV0@@Z)
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
"public: __thiscall exception::exception(class exception const &)" (??
0exception@@QAE@ABV0@@Z)
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
"public: __thiscall exception::exception(class exception const &)" (??
0exception@@QAE@ABV0@@Z)
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
"const type_info::`vftable'" (??_7type_info@@6B@)
libcpmtd.lib(nomemory.obj) : error LNK2001: unresolved external symbol
"const type_info::`vftable'" (??_7type_info@@6B@)
Demo_LAPACK.obj : error LNK2001: unresolved external symbol "const
type_info::`vftable'" (??_7type_info@@6B@)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
"const type_info::`vftable'" (??_7type_info@@6B@)
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
"const type_info::`vftable'" (??_7type_info@@6B@)
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
"const type_info::`vftable'" (??_7type_info@@6B@)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol "public:
virtual __thiscall exception::~exception(void)" (??1exception@@UAE@XZ)
referenced in function __unwindfunclet$??0logic_error@std@@QAE@ABV?
$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@@Z$0
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
"public: virtual __thiscall exception::~exception(void)" (??
1exception@@UAE@XZ)
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
"public: virtual __thiscall exception::~exception(void)" (??
1exception@@UAE@XZ)
libcpmtd.lib(nomemory.obj) : error LNK2001: unresolved external symbol
"public: virtual __thiscall exception::~exception(void)" (??
1exception@@UAE@XZ)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol "public:
__thiscall exception::exception(void)" (??0exception@@QAE@XZ)
referenced in function "public: __thiscall
std::logic_error::logic_error(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > const &)" (??
0logic_error@std@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@1@@Z)
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
"public: __thiscall exception::exception(void)" (??0exception@@QAE@XZ)
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
"public: __thiscall exception::exception(void)" (??0exception@@QAE@XZ)
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
"void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
libcpmtd.lib(nomemory.obj) : error LNK2001: unresolved external symbol
"void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol "void
__cdecl operator delete(void *)" (??3@YAXPAX@Z) referenced in function
"public: virtual void * __thiscall std::logic_error::`scalar deleting
destructor'(unsigned int)" (??_Glogic_error@std@@UAEPAXI@Z)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
"void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
"void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
"void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
_memcpy
libcpmtd.lib(xwctomb.obj) : error LNK2001: unresolved external symbol
_memcpy
libcpmtd.lib(_tolower.obj) : error LNK2001: unresolved external symbol
_memcpy
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _memcpy
referenced in function "public: static char * __cdecl
std::char_traits<char>::copy(char *,char const *,unsigned int)" (?
copy@?$char_traits@D@std@@SAPADPADPBDI@Z)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
_memcpy
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
_memcpy
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
_memcpy
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _strlen
referenced in function "public: static unsigned int __cdecl
std::char_traits<char>::length(char const *)" (?length@?
$char_traits@D@std@@SAIPBD@Z)
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
_strlen
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
_strlen
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
_strlen
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
_memmove
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _memmove
referenced in function "public: static char * __cdecl
std::char_traits<char>::move(char *,char const *,unsigned int)" (?
move@?$char_traits@D@std@@SAPADPADPBDI@Z)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
_memmove
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
_memmove
libcpmtd.lib(string.obj) : error LNK2001: unresolved external symbol
_memmove
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
_free
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _free
referenced in function "void __cdecl std::_DebugHeapDelete<class
std::locale::facet>(class std::locale::facet *)" (??
$_DebugHeapDelete@Vfacet@locale@std@@@std@@YAXPAVfacet@locale@0@@Z)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
_free
libcpmtd.lib(ios.obj) : error LNK2001: unresolved external symbol
_free
libcpmtd.lib(xmutex.obj) : error LNK2001: unresolved external symbol
_free
Demo_LAPACK.obj : error LNK2001: unresolved external symbol "public:
__thiscall bad_cast::bad_cast(class bad_cast const &)" (??
0bad_cast@@QAE@ABV0@@Z)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
"public: __thiscall bad_cast::bad_cast(class bad_cast const &)" (??
0bad_cast@@QAE@ABV0@@Z)
Demo_LAPACK.obj : error LNK2001: unresolved external symbol "public:
virtual __thiscall bad_cast::~bad_cast(void)" (??1bad_cast@@UAE@XZ)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
"public: virtual __thiscall bad_cast::~bad_cast(void)" (??
1bad_cast@@UAE@XZ)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol "public:
__thiscall bad_cast::bad_cast(char const *)" (??0bad_cast@@QAE@PBD@Z)
referenced in function "class std::num_put<char,class
std::ostreambuf_iterator<char,struct std::char_traits<char> > > const
& __cdecl std::use_facet<class std::num_put<char,class
std::ostreambuf_iterator<char,struct std::char_traits<char> > > >
(class std::locale const &)" (??$use_facet@V?$num_put@DV?
$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@@std@@YAABV?
$num_put@DV?$ostreambuf_iterator@DU?
$char_traits@D@std@@@std@@@0@ABVlocale@0@@Z)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
"public: __thiscall bad_cast::bad_cast(char const *)" (??
0bad_cast@@QAE@PBD@Z)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _sprintf
referenced in function "protected: virtual class
std::ostreambuf_iterator<char,struct std::char_traits<char> >
__thiscall std::num_put<char,class
std::ostreambuf_iterator<char,struct std::char_traits<char> > >::do_put
(class std::ostreambuf_iterator<char,struct std::char_traits<char>
>,class std::ios_base &,char,long)const " (?do_put@?$num_put@DV?
$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@MBE?AV?
$ostreambuf_iterator@DU?$char_traits@D@std@@@2@V32@AAVios_base@2@DJ@Z)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _strcspn
referenced in function "private: class
std::ostreambuf_iterator<char,struct std::char_traits<char> > __cdecl
std::num_put<char,class std::ostreambuf_iterator<char,struct
std::char_traits<char> > >::_Fput(class
std::ostreambuf_iterator<char,struct std::char_traits<char> >,class
std::ios_base &,char,char const *,unsigned int,unsigned int,unsigned
int,unsigned int)const " (?_Fput@?$num_put@DV?$ostreambuf_iterator@DU?
$char_traits@D@std@@@std@@@std@@ABA?AV?$ostreambuf_iterator@DU?
$char_traits@D@std@@@2@V32@AAVios_base@2@DPBDIIII@Z)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _memchr
referenced in function "private: class
std::ostreambuf_iterator<char,struct std::char_traits<char> > __cdecl
std::num_put<char,class std::ostreambuf_iterator<char,struct
std::char_traits<char> > >::_Fput(class
std::ostreambuf_iterator<char,struct std::char_traits<char> >,class
std::ios_base &,char,char const *,unsigned int,unsigned int,unsigned
int,unsigned int)const " (?_Fput@?$num_put@DV?$ostreambuf_iterator@DU?
$char_traits@D@std@@@std@@@std@@ABA?AV?$ostreambuf_iterator@DU?
$char_traits@D@std@@@2@V32@AAVios_base@2@DPBDIIII@Z)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol
_localeconv referenced in function "private: class
std::ostreambuf_iterator<char,struct std::char_traits<char> > __cdecl
std::num_put<char,class std::ostreambuf_iterator<char,struct
std::char_traits<char> > >::_Fput(class
std::ostreambuf_iterator<char,struct std::char_traits<char> >,class
std::ios_base &,char,char const *,unsigned int,unsigned int,unsigned
int,unsigned int)const " (?_Fput@?$num_put@DV?$ostreambuf_iterator@DU?
$char_traits@D@std@@@std@@@std@@ABA?AV?$ostreambuf_iterator@DU?
$char_traits@D@std@@@2@V32@AAVios_base@2@DPBDIIII@Z)
Demo_LAPACK.obj : error LNK2019: unresolved external symbol _memset
referenced in function "public: static char * __cdecl
std::char_traits<char>::assign(char *,unsigned int,char)" (?assign@?
$char_traits@D@std@@SAPADPADID@Z)
libcpmtd.lib(cout.obj) : error LNK2001: unresolved external symbol
_memset
LINK : error LNK2001: unresolved external symbol _mainCRTStartup
libcpmtd.lib(nomemory.obj) : error LNK2001: unresolved external symbol
_atexit
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_atexit referenced in function _$E1
libcpmtd.lib(xlock.obj) : error LNK2001: unresolved external symbol
_atexit
libcpmtd.lib(locale0.obj) : error LNK2001: unresolved external symbol
_atexit
libcpmtd.lib(iosptrs.obj) : error LNK2001: unresolved external symbol
_atexit
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
___iob_func referenced in function _$E4
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_fwrite referenced in function "protected: virtual int __thiscall
std::basic_filebuf<char,struct std::char_traits<char> >::overflow
(int)" (?overflow@?$basic_filebuf@DU?
$char_traits@D@std@@@std@@MAEHH@Z)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
___security_cookie referenced in function "protected: virtual int
__thiscall std::basic_filebuf<char,struct std::char_traits<char>
>::overflow(int)" (?overflow@?$basic_filebuf@DU?
$char_traits@D@std@@@std@@MAEHH@Z)
libcpmtd.lib(xwctomb.obj) : error LNK2001: unresolved external symbol
___security_cookie
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
@__security_check_cookie@4 referenced in function "protected: virtual
int __thiscall std::basic_filebuf<char,struct std::char_traits<char>
>::overflow(int)" (?overflow@?$basic_filebuf@DU?
$char_traits@D@std@@@std@@MAEHH@Z)
libcpmtd.lib(xwctomb.obj) : error LNK2001: unresolved external symbol
@__security_check_cookie@4
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_fputc referenced in function "bool __cdecl std::_Fputc<char>
(char,struct _iobuf *)" (??$_Fputc@D@std@@YA_NDPAU_iobuf@@@Z)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_ungetc referenced in function "bool __cdecl std::_Ungetc<char>(char
const &,struct _iobuf *)" (??$_Ungetc@D@std@@YA_NABDPAU_iobuf@@@Z)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_fgetc referenced in function "protected: virtual int __thiscall
std::basic_filebuf<char,struct std::char_traits<char> >::uflow
(void)" (?uflow@?$basic_filebuf@DU?$char_traits@D@std@@@std@@MAEHXZ)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_fgetpos referenced in function "protected: virtual class
std::fpos<int> __thiscall std::basic_filebuf<char,struct
std::char_traits<char> >::seekoff(long,int,int)" (?seekoff@?
$basic_filebuf@DU?$char_traits@D@std@@@std@@MAE?AV?$fpos@H@2@JHH@Z)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_fseek referenced in function "protected: virtual class std::fpos<int>
__thiscall std::basic_filebuf<char,struct std::char_traits<char>
>::seekoff(long,int,int)" (?seekoff@?$basic_filebuf@DU?
$char_traits@D@std@@@std@@MAE?AV?$fpos@H@2@JHH@Z)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_fsetpos referenced in function "protected: virtual class
std::fpos<int> __thiscall std::basic_filebuf<char,struct
std::char_traits<char> >::seekpos(class std::fpos<int>,int)" (?
seekpos@?$basic_filebuf@DU?$char_traits@D@std@@@std@@MAE?AV?
$fpos@H@2@V32@H@Z)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_setvbuf referenced in function "protected: virtual class
std::basic_streambuf<char,struct std::char_traits<char> > * __thiscall
std::basic_filebuf<char,struct std::char_traits<char> >::setbuf(char
*,int)" (?setbuf@?$basic_filebuf@DU?$char_traits@D@std@@@std@@MAEPAV?
$basic_streambuf@DU?$char_traits@D@std@@@2@PADH@Z)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_fflush referenced in function "protected: virtual int __thiscall
std::basic_filebuf<char,struct std::char_traits<char> >::sync(void)" (?
sync@?$basic_filebuf@DU?$char_traits@D@std@@@std@@MAEHXZ)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
_fclose referenced in function "public: class
std::basic_filebuf<char,struct std::char_traits<char> > * __thiscall
std::basic_filebuf<char,struct std::char_traits<char> >::close
(void)" (?close@?$basic_filebuf@DU?
$char_traits@D@std@@@std@@QAEPAV12@XZ)
libcpmtd.lib(cout.obj) : error LNK2019: unresolved external symbol
"void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) referenced in
function "protected: void __thiscall std::ctype<char>::_Tidy(void)" (?
_Tidy@?$ctype@D@std@@IAEXXZ)
libcpmtd.lib(uncaught.obj) : error LNK2019: unresolved external symbol
"bool __cdecl __uncaught_exception(void)" (?
__uncaught_exception@@YA_NXZ) referenced in function "bool __cdecl
std::uncaught_exception(void)" (?uncaught_exception@std@@YA_NXZ)
libcpmtd.lib(locale0.obj) : error LNK2019: unresolved external symbol
_setlocale referenced in function "public: __thiscall
std::_Locinfo::_Locinfo(char const *)" (??0_Locinfo@std@@QAE@PBD@Z)
libcpmtd.lib(locale0.obj) : error LNK2019: unresolved external symbol
_memcmp referenced in function "public: static int __cdecl
std::char_traits<char>::compare(char const *,char const *,unsigned
int)" (?compare@?$char_traits@D@std@@SAHPBD0I@Z)
libcpmtd.lib(newop.obj) : error LNK2019: unresolved external symbol
__callnewh referenced in function "void * __cdecl operator new
(unsigned int)" (??2@YAPAXI@Z)
libcpmtd.lib(newop.obj) : error LNK2019: unresolved external symbol
_malloc referenced in function "void * __cdecl operator new(unsigned
int)" (??2@YAPAXI@Z)
libcpmtd.lib(xdebug.obj) : error LNK2019: unresolved external symbol
__malloc_dbg referenced in function "void * __cdecl operator new
(unsigned int,struct std::_DebugHeapTag_t const &,char *,int)" (??
2@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z)
libcpmtd.lib(_tolower.obj) : error LNK2001: unresolved external symbol
__malloc_dbg
libcpmtd.lib(xdebug.obj) : error LNK2019: unresolved external symbol
__free_dbg referenced in function "void __cdecl operator delete(void
*,struct std::_DebugHeapTag_t const &,char *,int)" (??
3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z)
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
__unlock referenced in function __Wcrtomb
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
__unlock referenced in function __Tolower
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
__unlock referenced in function __Toupper
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
__lock referenced in function __Wcrtomb
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
__lock referenced in function __Tolower
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
__lock referenced in function __Toupper
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
____setlc_active_func referenced in function __Wcrtomb
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
____setlc_active_func referenced in function __Tolower
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
____setlc_active_func referenced in function __Toupper
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
____unguarded_readlc_active_add_func referenced in function __Wcrtomb
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
____unguarded_readlc_active_add_func referenced in function __Tolower
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
____unguarded_readlc_active_add_func referenced in function __Toupper
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
__except_handler3 referenced in function __Wcrtomb
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
__except_handler3 referenced in function __Tolower
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
__except_handler3 referenced in function __Toupper
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
____mb_cur_max_func referenced in function ___Wcrtomb_lk
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
__errno referenced in function ___Wcrtomb_lk
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
____lc_codepage_func referenced in function ___Wcrtomb_lk
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
____lc_codepage_func referenced in function __Tolower_lk
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
____lc_codepage_func referenced in function __Toupper_lk
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
____lc_handle_func referenced in function ___Wcrtomb_lk
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
____lc_handle_func referenced in function __Tolower_lk
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
____lc_handle_func referenced in function __Toupper_lk
libcpmtd.lib(xwctomb.obj) : error LNK2019: unresolved external symbol
__local_unwind2 referenced in function _wcsrtombs
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
___crtLCMapStringA referenced in function __Tolower_lk
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
___crtLCMapStringA referenced in function __Toupper_lk
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
___pctype_func referenced in function __Tolower_lk
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
___pctype_func referenced in function __Toupper_lk
libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
_isupper referenced in function __Tolower_lk
libcpmtd.lib(_toupper.obj) : error LNK2019: unresolved external symbol
_islower referenced in function __Toupper_lk
libcpmtd.lib(iosptrs.obj) : error LNK2019: unresolved external symbol
_abort referenced in function __Atexit
libcpmtd.lib(nomemory.obj) : error LNK2001: unresolved external symbol
"public: virtual char const * __thiscall exception::what(void)const
" (?what@exception@@UBEPBDXZ)
libcpmtd.lib(nomemory.obj) : error LNK2019: unresolved external symbol
"public: __thiscall exception::exception(char const * const &)" (??
0exception@@QAE@ABQBD@Z) referenced in function "public: __thiscall
std::bad_alloc::bad_alloc(char const *)" (??0bad_alloc@std@@QAE@PBD@Z)
Debug/TestBed.exe : fatal error LNK1120: 71 unresolved externals
Olumide
libatlas.lib, vcf2c.lib, lapack_win32.lib, libcblas.lib, cblas.lib,
liblapack.lib, amassed over the past few months but I'm still getting
a whole bunch of errors:
Mark Hoemmen
> I'm trying to compile and link the C++ program http://matrixprogramming.com/LAPACK/dgesv.cpp
> with Visual studio (using a GotoBLAS library compiled in Cygwin). The
> compilation works fine, but linking fails with the error message given
> below.
>
> Demo_LAPACK.obj : error LNK2019: unresolved external symbol _fabs
> referenced in function _main
Did you link with the math library? (-lm)
> Demo_LAPACK.obj : error LNK2019: unresolved external symbol _DGESV
> referenced in function _main
Did you link with the (Goto)BLAS? Is the symbol for DGESV in the
GotoBLAS library the same as the extern symbol used in the code example?
(There may be a difference beween Fortran symbols and C symbols -- some
compilers bind Fortran symbols to their lowercase versions with an
underscore attached.)
You should use a pastebin website to show us the error messages, rather
than attaching them all in a very long e-mail sent to everyone on the
list ;-)
http://en.wikipedia.org/wiki/Pastebin
mfh
Evgenii Rudnyi
> Hi,
>
> I'm trying to compile and link the C++ program http://matrixprogramming.com/LAPACK/dgesv.cpp
> with Visual studio (using a GotoBLAS library compiled in Cygwin). The
> compilation works fine, but linking fails with the error message given
> below.
You have to use -mno-cygwin if you want to use libraries with VS. Have
you used it? Without this, it will not work.
You may need to rename DGESV in the code. It depend on how it is called
in GotoBLAS.
Evgenii Rudnyi
> I've tried linking with the following library files, blas_win32.lib,
> libatlas.lib, vcf2c.lib, lapack_win32.lib, libcblas.lib, cblas.lib,
> liblapack.lib, amassed over the past few months but I'm still getting
> a whole bunch of errors:
Using libraries compiled by different compilers is not a trivial task.
For C++, I guess, it will not work in general. For C and Fortran 77 it
may work if you are lucky. Actually if you try with VC to mix different
system libraries -MD, -MT and so on, you will have the same problem. For
the latter please look at
http://support.microsoft.com/kb/154753
I see in German, but I hope that for you it will be in your language.
If you use different versions of a compiler, you may have again the same
problem. Anyway, basically you have to be patient and understand what is
going on. Everything is possible and opportunities are endless. The
question is how much time it will take. It might be just faster to
recompile everything with one compiler.
Your friend is nm under cygwin. It tells you what names are defined in
the libraries.
Unfortunately I did not have time yet to look at GotoBLAS. But let us
compile the code with ATLAS. Do not forget that libraries from TAUCS are
compiled with -MT. So let us start with -MT
$ cl -MT -EHsc dgesv.cpp liblapack.lib libf77blas.lib libcblas.lib
libatlas.lib vcf2c.lib
dgesv.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol
"_DGESV" in Funktion "_main".
dgesv.exe : fatal error LNK1120: 1 nicht aufgelöste externe Verweise.
Well, _DGESV is missing and this is correct as ATLAS uses different BLAS
names. We can easily figure this out with nm
$ nm liblapack.lib | grep -i dgesv
00000010 T _dgesv_
Note that I knew that this must be in liblapack. In the general case you
have to search over all the libraries. So we see that we need to use
dgesv_. If now I edit dgesv.cpp and change DGESV to dgesv_, then the
command above compiles.
The next step let us switch to -MD
$ cl -MD -EHsc dgesv.cpp liblapack.lib libf77blas.lib libcblas.lib
libatlas.lib vcf2c.lib
There are already many missing symbols, as vcf2c.lib was compiled with
-MT. We already have discussed it and found a combination of libraries
that will work with -MD
http://matrixprogramming.com/TAUCS/taucs-MD.html
See Using ATLAS as optimized BLAS
Let us try it
$ cl -MD -EHsc dgesv.cpp liblapack.lib libf77blas.lib libcblas.lib
libatlas.lib libg2c.lib libgcc.lib
By me everything is okay.
Once more, patience, patience, and patience. This what is necessary if
you want to mix libraries from different compilers.
Olumide
> > libatlas.lib, vcf2c.lib, lapack_win32.lib, libcblas.lib, cblas.lib,
> > liblapack.lib, amassed over the past few months but I'm still getting
> > a whole bunch of errors:
>
> Using libraries compiled by different compilers is not a trivial task.
> For C++, I guess, it will not work in general. For C and Fortran 77 it
> may work if you are lucky. Actually if you try with VC to mix different
> system libraries -MD, -MT and so on, you will have the same problem. For
> the latter please look at
Visual Studio (C++) projects. Some of them come from GLS, some from
TAUCS, some from MUMPS etc, and they work well, probably because they
were built for different matrix libraries I mentioned. I only decided
to try in my latest project when the GotoBLAS lib did not work. I
suppose the linker errors I got indicate that the symbols(?) generated
by the compiler (compilation phase worked), were not found in any of
the libraries I supplied. BTW, thanks a lot for showing me the nm
command :-) , I've been looking for something like it. Its literally
opened up a new world of knowledge that I'm eager to discover. More
about nm later.
> http://support.microsoft.com/kb/154753
>
> I see in German, but I hope that for you it will be in your language.
longer live in Germany.)
> If you use different versions of a compiler, you may have again the same
> problem. Anyway, basically you have to be patient and understand what is
> going on. Everything is possible and opportunities are endless. The
> question is how much time it will take. It might be just faster to
> recompile everything with one compiler.
sure which of the LAPACK libs I've collected over the past few weeks/
months to use e.g. lapack_win32.lib, liblapack.lib. In the past, I've
merely used (sparse) Matrix libraries based on LAPACK (which came
along with the various precompiled libs listed above), but now I'm
trying to use LAPACK by itself.
> Your friend is nm under cygwin. It tells you what names are defined in
> the libraries.
> Unfortunately I did not have time yet to look at GotoBLAS.
perform a no frills compile, and only minute tweaks to customize. Even
a n00b like me found it trivial.
> Well, _DGESV is missing and this is correct as ATLAS uses different BLAS
> names. We can easily figure this out with nm
>
> $ nm liblapack.lib | grep -i dgesv
>
> 00000010 T _dgesv_
(thanks Mark). GotoBLAS too uses _dgesv_ .
Quick question: its just occurred to me most of the other linker
errors I'm getting are about not finding the symbols _clock, _rand,
_atoi etc. (used in dgesv.cpp). Why are the functions(?) prepended
with an underscore?
I will try the command line compilation steps you recommended and see
if I get different results.
> Once more, patience, patience, and patience. This what is necessary if
> you want to mix libraries from different compilers.
this sort of thing.
Olumide
> you used it? Without this, it will not work.
generated by the GotoBLAS build process:
gcc -c -O2 -D_GNU_SOURCE -DWINDOWS_ABI -Wall -m32 -DF_INTERFACE_F2C -
DNEED_F2CCO NV -DMAX_CPU_NUMBER=2 -DNUM_BUFFERS=\(2*2\) -
DASMNAME=_cpotri -DASMFNAME=_cpotri _ -DNAME=cpotri_ -DCNAME=cpotri -
DFUNDERSCORE=_ -DNEEDFUNDERSCORE -DBUNDERSCORE=_ -DNEEDBUNDERSCORE -
I../.. -DARCH_X86 -DPENTIUMM -DL1_CODE_SIZE=32768 -
DL1_CODE_ASSOCIATIVE=8 -DL1_CODE_LINESIZE=64 -DL1_DATA_SIZE=32768 -
DL1_DATA_ASSOCIATIVE=8 -DL1_DATA_LINESIZE=64 -DL2_SIZE=1048576 -
DL2_ASSOCIATIVE=8 -DL2_LINESIZE=64 -DITB_SIZE=4096 -DITB_ASSOCIATIVE=4
-DITB_ENTRIES=128 -DDTB_SIZE=4096 -DDTB_ASSOCIATIVE=4 -
DDTB_ENTRIES=128 -DHAVE_CMOV -DHAVE_MMX -DHAVE_SSE -DHAVE_SSE2 -
DHAVE_CFLUSH -DNUM_SHAREDCACHE=1 -DNUM_CORES=1 -DCORE_BANIAS -
DCOMPLEX -UDOUBLE zpotri.c -o cpotri.o
Will it generate a VS linkable object? I've asked the folks at the
Cygwin mailing list about it. Here's what they said:
http://www.nabble.com/Using-Cygwin-compiled-libs-in-Visual-Studio-td22811487.html
Olumide
deleoper of GotoBLAS, I need to create a DLL that's linkable to/by a
VS generated-binary (my phrasing), in order to use GotoBLAS with VS.
Mark Hoemmen
>> Unfortunately I did not have time yet to look at GotoBLAS.
>
> Try it when you get the time. Its requires no tweaks whatsoever to
> perform a no frills compile, and only minute tweaks to customize. Even
> a n00b like me found it trivial.
*nods* let me also reassure you that this is the case. Mr. Goto has
done an excellent job here, even if his spelling in the README isn't
so good.
> Here is the output of nm on the GotoBLAS lib http://pastebin.com/f14d74312
> (thanks Mark). GotoBLAS too uses _dgesv_ .
Sorry if I was a bit mean about using pastebin -- it's just that it's
much easier to read short e-mails ;-)
> Quick question: its just occurred to me most of the other linker
> errors I'm getting are about not finding the symbols _clock, _rand,
> _atoi etc. (used in dgesv.cpp). Why are the functions(?) prepended
> with an underscore?
Different compilers have different conventions for transforming the
name of a function or method name or a globally visible variable into
a symbol in the machine code. Those machine code symbols are the
"actual names" that represent the "interface" of a library or object
file. This transformation process is often called "name mangling"
(especially in the context of C++, which actually does _mangle_ the
names almost beyond recognition). Name mangling is why you need to
use extern "C" to declare the interface of a C function in a C++ file;
otherwise the C++ compiler assumes that the function is a C++ function
and performs C++ mangling on the name to get the linker symbol.
mfh
Mark Hoemmen
Why not just use a static library?
mfh
Olumide
> > deleoper of GotoBLAS, I need to create a DLL that's linkable to/by a
> > VS generated-binary (my phrasing), in order to use GotoBLAS with VS.
>
> Why not just use a static library?
the static library compiled by Cygwin cannot be linked in VS. Anyway,
my plan for now is to first compile and link a test program in VS,
using the generic (unoptimized) BLAS, and later switch to GotoBLAS.
Here's the result of my latest attempt with CLAPACK. I thought it
would be easier to get CLAPACK working in VS ...
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1401
BTW, I didn't think you were mean about your advise that I use
pastebin. I don't receive mail messages from the forum, and I'd
forgotten that some people actually do. Anyway, pastbin's great. I'll
be using it from now on.
Olumide
> the static library compiled by Cygwin cannot be linked in VS. Anyway,
> my plan for now is to first compile and link a test program in VS,
> using the generic (unoptimized) BLAS, and later switch to GotoBLAS.
I thought.
All it requires is to execute "make dll" in the exports directory of
the distribution. Note that this requires the lib.exe and mspdb80.dll
that come with VS.
Now to get the whole thing working ...
Evgenii Rudnyi
...
>> Quick question: its just occurred to me most of the other linker
>> errors I'm getting are about not finding the symbols _clock, _rand,
>> _atoi etc. (used in dgesv.cpp). Why are the functions(?) prepended
>> with an underscore?
>
> Different compilers have different conventions for transforming the
> name of a function or method name or a globally visible variable into
> a symbol in the machine code. Those machine code symbols are the
> "actual names" that represent the "interface" of a library or object
> file. This transformation process is often called "name mangling"
> (especially in the context of C++, which actually does _mangle_ the
> names almost beyond recognition). Name mangling is why you need to
> use extern "C" to declare the interface of a C function in a C++ file;
> otherwise the C++ compiler assumes that the function is a C++ function
> and performs C++ mangling on the name to get the linker symbol.
It seems that the question was about something else. The compiler
usually prepends underscore to functions to distinguish them from some
internal symbols, if I remember it correctly. Anyway, it seems that the
first underscore is quite common. The Fortran compilers, on the other
hand, used to prepend and append the underscore together.
Name mangling comes on top of this. Things with underscore happens
already with Fortran and C.
Evgenii Rudnyi
Cygwin is basically a tool to port Unix code to Windows. As such, it
emulates Unix calls. To achieve it, it uses cygwin1.dll and the code
compiled with gcc depends on it. Or one can say that Cygwin by default
uses Unix-like system libraries that in turn depends on cygwin1.dll.
Hence, the object file produced by default has basically Unix-like
system calls and it is hard to link it with VS. It is probably could be
possible but with a lot of headache.
An alternative to Cygwin was MinGW, that allows us to use gcc but
directly use Win32. MinGW is now a part of Cygwin and one turns it on
with the option -mno-cygwin. However, this way the code should not have
Unix system calls, only standard C library calls or Win32 calls. It
could be possible to insert -mno-cygwin in GotoBLAS but if it uses Unix
system calls, then it will not work.
The solution with DLL seems to be the best. This way the code will
depend on cygwin1.dll but this should not be a problem for you. A legal
problem with cygwin1.dll that you either must distribute your code under
GNU or must purchase a special license to distribute cygwin1.dll.
Mark Hoemmen
I see, the question was about something particular to VS. (Not all
compilers prepend underscores to functions.)
> Name mangling comes on top of this. Things with underscore happens
> already with Fortran and C.
I usually use the term "name mangling" to refer to any compiler's
convention for transforming programmer-visible symbols into
linker-visible symbols, regardless of the language. I suppose that's
a quirk of mine ;-)
mfh
Evgenii Rudnyi
> On Thu, Apr 23, 2009 at 12:07, Evgenii Rudnyi <use...@rudnyi.ru> wrote:
>>>> Quick question: its just occurred to me most of the other linker
>>>> errors I'm getting are about not finding the symbols _clock, _rand,
>>>> _atoi etc. (used in dgesv.cpp). Why are the functions(?) prepended
>>>> with an underscore?
>>> Different compilers have different conventions for transforming the
>>> name of a function or method name or a globally visible variable into
>>> a symbol in the machine code. Those machine code symbols are the
>>> "actual names" that represent the "interface" of a library or object
>>> file. This transformation process is often called "name mangling"
>>> (especially in the context of C++, which actually does _mangle_ the
>>> names almost beyond recognition). Name mangling is why you need to
>>> use extern "C" to declare the interface of a C function in a C++ file;
>>> otherwise the C++ compiler assumes that the function is a C++ function
>>> and performs C++ mangling on the name to get the linker symbol.
>> It seems that the question was about something else. The compiler
>> usually prepends underscore to functions to distinguish them from some
>> internal symbols, if I remember it correctly. Anyway, it seems that the
>> first underscore is quite common. The Fortran compilers, on the other
>> hand, used to prepend and append the underscore together.
>
> I see, the question was about something particular to VS. (Not all
> compilers prepend underscores to functions.)
In my experience it is quite common. It is certainly not VS specific.
Say, gcc does it and actually I do not remember a compiler that does not
do it.
Well, probably it was not the case on BESM6
but this was so long ago that I do not remember anymore.
Mark Hoemmen
> Mark Hoemmen schrieb:
>> I see, the question was about something particular to VS. (Not all
>> compilers prepend underscores to functions.)
>
> In my experience it is quite common. It is certainly not VS specific.
> Say, gcc does it and actually I do not remember a compiler that does not
> do it.
g77 and gfortran both append an underscore to Fortran symbols. I've
encountered some compilers (IBM's xlf, perhaps?) that do not.
The Fortran 2003 standard introduced the ISO_C_BINDING module, which
lets you declare Fortran functions to have C binding (so you can specify
what symbol should be exported to the linker). It also lets you pass
scalars by value instead of by pointer. I'm using ISO_C_BINDING in a
project now and it's a big help, especially in mixed Fortran / C
projects. It's also handy if you want to roll your own C BLAS interface.
mfh
Evgenii Rudnyi
Actually you can control it with g77 with -fno-underscoring. But this is
only one part of the story. The second part is that the all these
compilers including C prepend underscore. And I am not sure that this
behavior could be changed.
Olumide
> I thought.
http://pastebin.com/f6ebd442f) with the reference BLAS.
The next problem I need to solve is how to use the GotoBLAS
(libgoto_banias-r1.26.lib) compiled for my machine instead of the
reference BLAS. A simple substitution of the reference BLAS with the
GotoBLAS library produces the following linker errors:
timer_dgesv.obj : error LNK2001: unresolved external symbol _f2c_dcopy
timer_dgesv.obj : error LNK2001: unresolved external symbol _f2c_dnrm2
timer_dgesv.obj : error LNK2001: unresolved external symbol _f2c_dgemm
Clearly, there are no such symbols in libgoto_banias-r1.26.lib.
Output of the command "nm libgoto_banias-r1.26.lib": http://pastebin.com/f6ef6e40d
Evgenii Rudnyi
...
> Here's the result of my latest attempt with CLAPACK. I thought it
> would be easier to get CLAPACK working in VS ...
> http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1401
I should confess that I have never compiled CLAPACK. I have just used
LAPACK directly. Clearly one needs a Fortran compiler to compile LAPACK
but then one can calls it from C and C++.
From docs it seems that they have used f2c to convert the Fortran code
to C and then compile it. I would expect that if one compiles the
Fortran code directly, it should be faster.
Yet, if there is no Fortran compiler at hand, then CLAPACK could be a
solution.
Evgenii Rudnyi
But why do you use these strange names in your code? You cannot expect
to find them in any normal BLAS library. Say, ATLAS does not have them.
It seems that this is very CLAPACK specific.
There are standard BLAS functions
http://www.netlib.org/lapack/lug/node145.html
Well, the word standard unfortunately does not imply what will these
names will look like in the library - uppercase or lowercase, with an
appended underscore or not. So, this is the first goal to learn how
these functions are named in a particular BLAS, say GotoBLAS and then
just use these names.
Olumide
> > Output of the command "nm libgoto_banias-r1.26.lib":http://pastebin.com/f6ef6e40d
>
> But why do you use these strange names in your code? You cannot expect
> to find them in any normal BLAS library. Say, ATLAS does not have them.
> It seems that this is very CLAPACK specific.
look into compiling LAPACK in Cygwin.
Evgenii Rudnyi
I understand. But my point was that these names come from your code. If
you change them in your code to those that are available in the GotoBLAS
then it may work. Also I see that GotoBLAS already has some LAPACK
routines, say it seems that dgesv should be already there.
The reason for that is that actually LAPACK routines should be tuned as
well. At least this concerns ILAENV
http://www.netlib.org/lapack/lug/node131.html
but usually people tune other routines as well. So, GotoBLAS and ATLAS
are actually more than just optimized BLAS. It might well be that it is
just enough for you.
If not, then for example in ATLAS there are instruction how to make a
full LAPACK
http://math-atlas.sourceforge.net/errata.html#completelp
Check what says the GotoBLAS docs.
I guess that this sounds pretty confusing but the life is usually a mess
anyway.
Olumide
> > look into compiling LAPACK in Cygwin.
>
> I understand. But my point was that these names come from your code. If
> you change them in your code to those that are available in the GotoBLAS
> then it may work. Also I see that GotoBLAS already has some LAPACK
> routines, say it seems that dgesv should be already there.
1. The sample code is not mine. Its a CLAPACK example.
2. GotoBLAS indeed implements several LAPACK routines. Kazushige Goto,
the author of the library confirms this. I imagine such LAPACK
functions implemented in BLAS are "superior" to their native/untuned
counterparts. If so, I wonder how the linker(?) can be made to use the
BLAS versions instead of the LAPACK ones. Will placing the GotoBLAS
lib before the LAPACK lib guarantee this?
> but usually people tune other routines as well. So, GotoBLAS and ATLAS
> are actually more than just optimized BLAS. It might well be that it is
> just enough for you.
>
> If not, then for example in ATLAS there are instruction how to make a
> full LAPACK
>
> http://math-atlas.sourceforge.net/errata.html#completelp
>
> Check what says the GotoBLAS docs.
I'll compile it after I get back from the dance :-)
Mark Hoemmen
> 1. The sample code is not mine. Its a CLAPACK example.
>
> 2. GotoBLAS indeed implements several LAPACK routines. Kazushige Goto,
> the author of the library confirms this.
Look in the lapack directory in Goto's BLAS' source distribution to see
exactly which LAPACK routines Goto has implemented, to see if it affects
you. I see only various LU and Cholesky factorizations in there.
mfh
Olumide
> > to find them in any normal BLAS library. Say, ATLAS does not have them.
> > It seems that this is very CLAPACK specific.
>
> I'm using CLAPACK because that's the only library that I have. I'll
> look into compiling LAPACK in Cygwin.
libraries on my machine courtesy of http://icl.cs.utk.edu/lapack-for-windows/
.
The problem now is how to use these libraries in order to compile the
following program [ http://www.cs.rochester.edu/~bh/cs400/using_lapack.html
] in Visual Studio.
Evgenii Rudnyi
>>> I'm using CLAPACK because that's the only library that I have. I'll
>>> look into compiling LAPACK in Cygwin.
>> I understand. But my point was that these names come from your code. If
>> you change them in your code to those that are available in the GotoBLAS
>> then it may work. Also I see that GotoBLAS already has some LAPACK
>> routines, say it seems that dgesv should be already there.
>
> Two minor points:
>
> 1. The sample code is not mine. Its a CLAPACK example.
Well, you try to use it. I am really surprised why they have made these
strange names.
> 2. GotoBLAS indeed implements several LAPACK routines. Kazushige Goto,
> the author of the library confirms this. I imagine such LAPACK
> functions implemented in BLAS are "superior" to their native/untuned
> counterparts. If so, I wonder how the linker(?) can be made to use the
> BLAS versions instead of the LAPACK ones. Will placing the GotoBLAS
> lib before the LAPACK lib guarantee this?
Linking with two libraries that define the same symbol is tricky and
highly linker dependent.
A better solution is to leave only one, the right symbol. For example,
this is how it is done in ATALS
Evgenii Rudnyi
Whey you start working with any BLAS and LAPACK library, the first
question is how the functions are named there. You can check it with nm
nm lapack.lib | grep -i dgesv
By default, the Intel Fortran on Windows uses uppercase and does not
append underscore. If this is the case with the libraries, you need to
rename the functions in the sample: dgesv_ to DGESV and dgels_ to DGELS.
Olumide
> question is how the functions are named there. You can check it with nm
>
> nm lapack.lib | grep -i dgesv
Release/dgesv.obj:
00000000 T _DGESV
Release/dgesvx.obj:
00000000 b DGESVX$NORM.0.0
00000000 T _DGESVX
Release/dgesvd.obj:
00000000 b DGESVD$DUM.0.0
00000000 T _DGESVD
Accordingly, I've tried renaming dgesv in the code to DGESV and then
_DGESV, but in both cases, I get linker errors ( i.e. unresolved
external symbol "void __cdecl _DGESV) -- even though the symbol exists
in the library (weird)!
Olumide
> _DGESV, but in both cases, I get linker errors ( i.e. unresolved
Actually, the complete message reads:
error LNK2019: unresolved external symbol "void __cdecl _DGESV(int
const *,int const *,double *,int const *,int *,double *,int const
*,int *)" (?_DGESV@@YAXPBH0PAN0PAH102@Z) referenced in function _main
Could it be that the linker is looking for the symbol "?
_DGESV@@YAXPBH0PAN0PAH102@Z" instead of "_DGESV"?
Evgenii Rudnyi
DGESV is correct. The compiler prepend always the underscore. The next
step would be to check how this function in the object file. Make nm on
the object file.
However the message
unresolved external symbol "void __cdecl _DGESV
says that it is okay.
Just double check that the linker search the library. It should be on
the path -L but additionally it should be put on the command line -l.
Well, for cl the flags are different.
Evgenii Rudnyi
Correct. This is the name mangling in C++. Use extern "C" before the
function name, that is
extern "C" void dgesv_(...);
Olumide
> step would be to check how this function in the object file. Make nm on
> the object file.
>
> However the message
>
> unresolved external symbol "void __cdecl _DGESV
>
> says that it is okay.
I'm getting the following linker errors:
lapackd.lib(xerbla.obj) : error LNK2019: unresolved external symbol
_for_write_seq_fmt referenced in function _XERBLA
lapackd.lib(dlamch.obj) : error LNK2001: unresolved external symbol
_for_write_seq_fmt
lapackd.lib(xerbla.obj) : error LNK2019: unresolved external symbol
_for_write_seq_fmt_xmit referenced in function _XERBLA
lapackd.lib(xerbla.obj) : error LNK2019: unresolved external symbol
_for_stop_core referenced in function _XERBLA
lapackd.lib(dgetrf.obj) : error LNK2019: unresolved external symbol
_for_emit_diagnostic referenced in function _DGETRF
lapackd.lib(ilaenv.obj) : error LNK2001: unresolved external symbol
_for_emit_diagnostic
lapackd.lib(dgetf2.obj) : error LNK2001: unresolved external symbol
_for_emit_diagnostic
lapackd.lib(dlaswp.obj) : error LNK2001: unresolved external symbol
_for_emit_diagnostic
lapackd.lib(ilaenv.obj) : error LNK2019: unresolved external symbol
_for_cpystr referenced in function _ILAENV
lapackd.lib(iparmq.obj) : error LNK2019: unresolved external symbol
_logf referenced in function _IPARMQ
lapackd.lib(iparmq.obj) : error LNK2019: unresolved external symbol
_f_lanint_val referenced in function _IPARMQ
lapackd.lib(dlamch.obj) : error LNK2019: unresolved external symbol
___powr8i4 referenced in function _DLAMCH
> Just double check that the linker search the library. It should be on
> the path -L but additionally it should be put on the command line -l.
> Well, for cl the flags are different.
linker searches the library.
BTW, I'm compiling in Visual Studio, not the command-line.
Evgenii Rudnyi
>> DGESV is correct. The compiler prepend always the underscore. The next
>> step would be to check how this function in the object file. Make nm on
>> the object file.
>>
>> However the message
>>
>> unresolved external symbol "void __cdecl _DGESV
>>
>> says that it is okay.
>
> I've renamed the function prototype to extern "C" void DGESV(...). Now
> I'm getting the following linker errors:
>
> lapackd.lib(xerbla.obj) : error LNK2019: unresolved external symbol
> _for_write_seq_fmt referenced in function _XERBLA
My guess is that the missing functions belong to the system libraries of
the Intel Fortran compiler. It seems that you have to link with them as
well. No luck. Ask the author of the library.
> BTW, I'm compiling in Visual Studio, not the command-line.
This does not matter provided everything is done correctly.
Olumide
> the Intel Fortran compiler. It seems that you have to link with them as
> well.
them to the project. Now all I'm left with is the linker error:
unresolved external symbol _errno referenced in function
___libm_error_support
Olumide
9.456125 -16.014625" (not 42 ;-) ).
Thanks Evgenii, Mark and the good people at comp.lang.fortran (
http://tinyurl.com/c7x2yl ) who helped put the last pieces of the
puzzle together.
Next: (Goto)BLAS integration and scaling the linear system.
Evgenii, perhaps you could make a page about this to help the next
n00b that comes around asking for help on how to use LAPACK in a VC++
project.
Mark Hoemmen
> Problem solved. Program now compiles. The answer is "-0.661082
> 9.456125 -16.014625" (not 42 ;-) ).
>
> Thanks Evgenii, Mark and the good people at comp.lang.fortran (
> http://tinyurl.com/c7x2yl ) who helped put the last pieces of the
> puzzle together.
Great work! You should know that this whole process of
reverse-engineering the linker and putting together a bunch of libraries
in order to get the right answer is something that occupies a lot of
time for folks like us. In particular, don't feel bad that it took this
long!
> Next: (Goto)BLAS integration and scaling the linear system.
>
> Evgenii, perhaps you could make a page about this to help the next
> n00b that comes around asking for help on how to use LAPACK in a VC++
> project.
I shouldn't speak for Evgenii, but it's always useful for me when I
encounter a similarly difficult problem, to write such a page myself and
then let experts critique it. That can be humbling though as I've found
myself ;-)
mfh
Olumide
On 27 Apr, 03:57, Mark Hoemmen <mark.hoem...@gmail.com> wrote:
> Great work! You should know that this whole process of
> reverse-engineering the linker and putting together a bunch of libraries
> in order to get the right answer is something that occupies a lot of
> time for folks like us. In particular, don't feel bad that it took this
> long!
having these problems. I would read a book about these things if I can
find one. (I'm tired of being a n00b in these matters.)
> > Next: (Goto)BLAS integration and scaling the linear system.
BLAS with GotoBLAS compiled for my system :-) . Also, I've managed to
reduce the list of fortran libraries to libifcorertd.lib and
libmmdd.lib.
Next step, timing tests of library type and matrix dimension. I'd like
to see for myself just how faster GotoBLAS is on my machine, and how
large my matrices can be before paging makes execution impossible.
> > Evgenii, perhaps you could make a page about this to help the next
> > n00b that comes around asking for help on how to use LAPACK in a VC++
> > project.
>
> I shouldn't speak for Evgenii, but it's always useful for me when I
> encounter a similarly difficult problem, to write such a page myself and
> then let experts critique it.
will put it up on matrixprogramming.com. I could put it on some blog,
but I think its best if all the useful information remained under "one
roof".
Evgenii Rudnyi
>
> On 27 Apr, 03:57, Mark Hoemmen <mark.hoem...@gmail.com> wrote:
>> Great work! You should know that this whole process of
>> reverse-engineering the linker and putting together a bunch of libraries
>> in order to get the right answer is something that occupies a lot of
>> time for folks like us. In particular, don't feel bad that it took this
>> long!
>
> Thanks for the reassuring words. I was starting to feel stupid for
> having these problems. I would read a book about these things if I can
> find one. (I'm tired of being a n00b in these matters.)
A very good paper in this respect is
David M. Beazley, Brian D. Ward, and Ian R. Cooke,
The Inside Story On Shared Libraries and Dynamic Loading,
Computing in Science & Engineering, September/October 2001, N 5, p. 90-97.
There is also very good book
John R. Levine, Linkers and Loaders
http://linker.iecc.com/
but it is more academic in nature.
>
>>> Next: (Goto)BLAS integration and scaling the linear system.
>
> I'm pleased to announce that I've successfully replaced the reference
> BLAS with GotoBLAS compiled for my system :-) . Also, I've managed to
> reduce the list of fortran libraries to libifcorertd.lib and
> libmmdd.lib.
Good news. Does GotoBLAS on Windows understand uppercase BLAS names
without underscore?
...
>>> Evgenii, perhaps you could make a page about this to help the next
>>> n00b that comes around asking for help on how to use LAPACK in a VC++
>>> project.
>> I shouldn't speak for Evgenii, but it's always useful for me when I
>> encounter a similarly difficult problem, to write such a page myself and
>> then let experts critique it.
>
> I don't mind writing such a doc with input from you guys, if Evgenii
> will put it up on matrixprogramming.com. I could put it on some blog,
> but I think its best if all the useful information remained under "one
> roof".
It would be my pleasure to put such a document to the site.
Olumide
>
> David M. Beazley, Brian D. Ward, and Ian R. Cooke,
> The Inside Story On Shared Libraries and Dynamic Loading,
> Computing in Science & Engineering, September/October 2001, N 5, p. 90-97.
>
> There is also very good book
>
> John R. Levine, Linkers and Loadershttp://linker.iecc.com/
> > I'm pleased to announce that I've successfully replaced the reference
> > BLAS with GotoBLAS compiled for my system :-) . Also, I've managed to
> > reduce the list of fortran libraries to libifcorertd.lib and
> > libmmdd.lib.
>
> Good news. Does GotoBLAS on Windows understand uppercase BLAS names
> without underscore?
dtrsv.o:
00000000 b .bss
00000000 d .data
00000000 r .rdata
00000000 t .text
U _blas_memory_alloc
U _blas_memory_free
00000000 T _dtrsv_
U _dtrsv_NLN
U _dtrsv_NLU
U _dtrsv_NUN
U _dtrsv_NUU
U _dtrsv_TLN
U _dtrsv_TLU
U _dtrsv_TUN
U _dtrsv_TUU
00000000 d _trsv
U _xerbla_
> > I don't mind writing such a doc with input from you guys, if Evgenii
> > will put it up on matrixprogramming.com. I could put it on some blog,
> > but I think its best if all the useful information remained under "one
> > roof".
>
> It would be my pleasure to put such a document to the site.
results from my timing experiments.
Evgenii Rudnyi
...
>> Good news. Does GotoBLAS on Windows understand uppercase BLAS names
>> without underscore?
>
> From what I can see, symbols in GotoBLAS have mixed case. For example:
>
> dtrsv.o:
> 00000000 b .bss
> 00000000 d .data
> 00000000 r .rdata
> 00000000 t .text
> U _blas_memory_alloc
> U _blas_memory_free
> 00000000 T _dtrsv_
> U _dtrsv_NLN
> U _dtrsv_NLU
> U _dtrsv_NUN
> U _dtrsv_NUU
> U _dtrsv_TLN
> U _dtrsv_TLU
> U _dtrsv_TUN
> U _dtrsv_TUU
> 00000000 d _trsv
> U _xerbla_
Well, this shows that actually GotoBLAS accepts only dtrsv_ as the only
allowable name. I do not know what the other names mean but U stays for
undefined anyway. So, this is an interesting question. How it was
possible that LAPACK compiled with the Intel Fortran on Windows is able
to call directly dtrsv_? In my understanding it should call DTRSV instead.
Well, this just shows that there are many things that are just above the
normal understanding. Yet, fortunately they are working!
Olumide
> allowable name. I do not know what the other names mean but U stays for
> undefined anyway. So, this is an interesting question. How it was
> possible that LAPACK compiled with the Intel Fortran on Windows is able
> to call directly dtrsv_? In my understanding it should call DTRSV instead.
>
> Well, this just shows that there are many things that are just above the
> normal understanding. Yet, fortunately they are working!
$ nm libgoto_banias-r1.26.lib | grep -i dtrsv
00000000 T _DTRSV
00000000 I __imp__DTRSV
00000000 I __imp__dtrsv
00000000 T _dtrsv
00000000 I __imp__dtrsv_
00000000 T _dtrsv_
Olumide
a few times and it appears that following copying operations:
vector<double> a1(a);
vector<double> b1(b);
(required for error computation) slows down the program a bit, and
will lead to paging especially when the matrix dimension is large. The
error computation itself is also quite slow.
From the little I've read, I believe that the "expert routine" DGESVX
can return the error in addition to solving the system. Are expert
routines the only routines that can compute errors?
It would be interesting to see how expert routine DGESVX performs in
comparison to the driver routine DGESV i.e. if the error computation
slows it down significantly. Problem is I'm that some parts of the
manual [ http://cc.in2p3.fr/doc/phpman.php/man/dgesvx/l ] are hard to
decipher. Can someone please help?
Thanks.
Mark Hoemmen
> From the little I've read, I believe that the "expert routine" DGESVX
> can return the error in addition to solving the system. Are expert
> routines the only routines that can compute errors?
Generally, yes. The idea is that if you "just want the answer," the
nonexpert routine should just return a reasonable answer. If you
really understand what the error means and you want to compute it, you
should call the expert routine.
> It would be interesting to see how expert routine DGESVX performs in
> comparison to the driver routine DGESV i.e. if the error computation
> slows it down significantly. Problem is I'm that some parts of the
> manual [ http://cc.in2p3.fr/doc/phpman.php/man/dgesvx/l ] are hard to
> decipher. Can someone please help?
You should read the LAPACK Users' Guide instead (it is available
online for free as in beer). The terms used in the manual pages will
make more sense once you do that.
In this case, iterative refinement (which both improves the solution's
accuracy and computes error bounds) costs a (usually) constant number
of dense matrix-vector multiplies. It should be much less
time-consuming than factoring the matrix, unless the matrix is very
very small.
mfh
Evgenii Rudnyi
> I've compiled and ran the example
> http://matrixprogramming.com/LAPACK/dgesv.cpp
> a few times and it appears that following copying operations:
>
> vector<double> a1(a);
> vector<double> b1(b);
>
> (required for error computation) slows down the program a bit, and
> will lead to paging especially when the matrix dimension is large. The
> error computation itself is also quite slow.
Actually it should be possible to use BLAS routines to compute the error.
I was too lazy to call them.
By the way, have you turned the safe iterators off in VS? See two
discussions about it - follow the links at the bottom of the next page
Olumide
> encounter a similarly difficult problem, to write such a page myself and
> then let experts critique it.
the guide in two because the Goto BLAS section required as much detail
as LAPACK part. Besides, Goto BLAS is worth having because it gives
excellent results, is easy to compile, and is free.
I await your constructive comments.
Olumide
> the guide in two because the Goto BLAS section required as much detail
> as LAPACK part. Besides, Goto BLAS is worth having because it gives
> excellent results, is easy to compile, and is free.
core) version of LAPACK for Windows [ http://www.netlib.org/scalapack/prototype/
] using Cygwin. I doesn't seem to perform any better than the basic
LAPACK, and that's probably why its remained a prototype for more than
14 years (its dated 1995).
Then again, I may have done something wrong in the build process: I
had to remove a couple of flags from the Makefile, and comment out
what seemed like a copy and paste error in one of the source files.
Mark Hoemmen
>> I've emailed a copy of my draft guide to you both. I decided to split
>> the guide in two because the Goto BLAS section required as much detail
>> as LAPACK part. Besides, Goto BLAS is worth having because it gives
>> excellent results, is easy to compile, and is free.
>
> By the way, I've also compiled and tested the prototype OOC (out of
> core) version of LAPACK for Windows [ http://www.netlib.org/scalapack/prototype/
Wouldn't that be ScaLAPACK, rather than LAPACK? OOC ScaLAPACK was
designed to exploit parallelism in the following ways:
1. on the panel factorizations and updates (which are performed using
ordinary ScaLAPACK factorization routines, if I recall correctly), and
2. on disk reads and writes (assuming your disk hardware and software
supports that).
As for #1, ScaLAPACK was designed with clusters and distributed memory
in mind. It can be hard (perhaps impossible?) to run with only one
processor. If you use a shared-memory MPI backend, you can productively
use ScaLAPACK on a single node with multiple processors, but it's known
that approaches specific to the shared-memory domain tend to perform
better. (I'm not talking about OOC yet.)
As for #2, the only way you'll get anything out of that on a single node
is if you have configured a RAID array of disks with striping to improve
aggregate disk bandwidth. On a cluster, you would need a
high-performance parallel filesystem (not NFS, something like Lustre or
GPFS).
> ] using Cygwin. I doesn't seem to perform any better than the basic
> LAPACK, and that's probably why its remained a prototype for more than
> 14 years (its dated 1995).
You should be proud you got it to work at all -- I'm impressed actually
;-) There has been some more recent work on parallel OOC solvers -- the
FLAME people (van de Geijn and ilk at UT Austin) worked on this.
mfh
Olumide
> > core) version of LAPACK for Windows [http://www.netlib.org/scalapack/prototype/
>
> Wouldn't that be ScaLAPACK, rather than LAPACK?
(LAWN -- just figured out the acronym :-) ) #118 --
http://www.netlib.org/lapack/lawns/lawn118.ps
However, I must confess that I am a bit confused about the merit of an
OOC LAPACK, because I thought LAPACK/BLAS (not sure which), are based
on block access/minimizing RAM or it disk accesses (not sure which),
which sounds a lot like what OOC LAPACK promises. Does this make
sense?
> > ] using Cygwin. I doesn't seem to perform any better than the basic
> > LAPACK, and that's probably why its remained a prototype for more than
> > 14 years (its dated 1995).
>
> You should be proud you got it to work at all -- I'm impressed actually
> ;-) There has been some more recent work on parallel OOC solvers -- the
> FLAME people (van de Geijn and ilk at UT Austin) worked on this.
sincerely hope that I know where to draw the line.
I've heard of the FLAME project, although I'm not entirely sure that I
understand what they are trying to do. It is a frame work, a library
or both? Anyway, page 6 of the FLAME complete reference document
states that the OOC feature is currently is not available but that
anyone interested in such functionality should contact their Spanish
colleagues, which I did, but I got mixed messages from them; namely:
the library is commercial, stability issues mean it cannot be
integrated into (or distributed with) liblflame etc.
Evgenii Rudnyi
...
> I've heard of the FLAME project, although I'm not entirely sure that I
> understand what they are trying to do. It is a frame work, a library
> or both? Anyway, page 6 of the FLAME complete reference document
> states that the OOC feature is currently is not available but that
> anyone interested in such functionality should contact their Spanish
> colleagues, which I did, but I got mixed messages from them; namely:
> the library is commercial, stability issues mean it cannot be
> integrated into (or distributed with) liblflame etc.
Once I have ordered and read the book written by the Flame authors (it
is actually free to download)
The Science of Programming Matrix Computations
http://www.lulu.com/content/1911788
The book is great but I have decided not to try FLAME. There are many
interesting things in this world but the available time unfortunately is
limited. In this respect you may want to look at small document that I
have recently written
Engineering Computing: Mixing Knowledge Transfer, Programming, and Numerics
http://evgenii.rudnyi.ru/doc/misc/EngineeringComputing.html
At some point it is important to choose the main goal and try to reach
it by just cutting the extra branches. Well, hopefully there will be
some more time after retirement.
Mark Hoemmen
>> > By the way, I've also compiled and tested the prototype OOC (out of
>> > core) version of LAPACK for Windows [http://www.netlib.org/scalapack/prototype/
>>
>> Wouldn't that be ScaLAPACK, rather than LAPACK?
>
> I think it's OOC LAPACK, possibly described in the LApack Working Note
> (LAWN -- just figured out the acronym :-) ) #118 --
> http://www.netlib.org/lapack/lawns/lawn118.ps
>
> However, I must confess that I am a bit confused about the merit of an
> OOC LAPACK, because I thought LAPACK/BLAS (not sure which), are based
> on block access/minimizing RAM or it disk accesses (not sure which),
> which sounds a lot like what OOC LAPACK promises. Does this make
> sense?
OOC is for solving problems that don't fit in RAM. LAPACK is designed
to reduce memory bandwidth requirements (and therefore increase
computational intensity) between cache and RAM. The problem is, the
relationship between virtual memory (or rather, disk swap space) and
RAM is very different than the relationship between RAM and cache:
1. The cache reads lines of data (usually 32, 64, or 128 bytes) from
RAM, whereas virtual memory comes in pages at a time (often >= 4K).
Bringing in a page from disk swap space to RAM, or pushing it out
again, is a much more expensive operation than bringing in a cache
line from RAM.
2. The operating system has to change between processes every so often
and every time it does that, it has to bring in a page belonging to
that process (since different processes aren't allowed to share memory
pages generally). So not only does the disk have to grind to fetch
and put back pages from your app, it has to grind whenever the OS
decides to let some other process (like a system daemon or your GUI)
run. This is also true for cache and DRAM, but a cache line fetch is
handled by hardware and has a latency of about 100 cycles, whereas
swapping pages is a huge system call kind of thing and disk latency
could be around a million cycles.
3. RAM may be >1000x as big as (L2 or L3) cache, but virtual memory
isn't much bigger than RAM itself. Thus, it's still easy to run out
of virtual memory, which is generally a disaster (on Linux with the
default settings, it results in some random process on the machine
being killed).
This means that OOC codes generally take the effort to manage data
movement between RAM and disk explicitly. They bound the amount of
data in RAM, and carefully do as little data movement between RAM and
disk as possible. LAPACK doesn't do this; it relies on the properties
of a cache in order to reduce data movement.
> I've heard of the FLAME project, although I'm not entirely sure that I
> understand what they are trying to do. It is a frame work, a library
> or both?
Both, sort of. You can use it as a library, or you can use it to
experiment with different matrix partitionings in the three one-sided
factorization algorithms (Cholesky, LU, QR).
> Anyway, page 6 of the FLAME complete reference document
> states that the OOC feature is currently is not available but that
> anyone interested in such functionality should contact their Spanish
> colleagues, which I did, but I got mixed messages from them; namely:
> the library is commercial, stability issues mean it cannot be
> integrated into (or distributed with) liblflame etc.
That's unfortunate. Van de Geijn seemed quite proud of their work
when he contacted us to clarify a point in one of our papers. If you
have a strong interest in the OOC feature and would find it very
useful for your work, I would recommend explaining the situation to
him and asking him to intervene so you can get the code or at least a
library. If that doesn't work, let me know and I'll try talking to
him.
mfh
Olumide
> online for free as in beer). The terms used in the manual pages will
> make more sense once you do that.
of the WORK array size argument of DSYSV [
http://www.math.utah.edu/software/lapack/lapack-d/dsysv.html ]. Is
LWORK best determined by calling the routine ILAENV? I don't know how
sensitive DSYSV is to the size of LWORK. (I am trying to solve a
symmetric, semi-definite, matrix of doubles.)
Mark Hoemmen
First, you should get the documentation for LAPACK functions from
www.netlib.org, as it is most likely to be up to date. (Nothing bad
about U of Utah per se.)
Second, any LAPACK function that has both a WORK and an LWORK parameter
lets you determine the best LWORK value by setting LWORK = -1 and
passing in a one-element array for WORK. If the call succeeds (INFO =
0), then WORK(1) will have been set to the optimal LWORK value. Then
you can set LWORK to that value, allocate the WORK array to that length
and call again.
The LWORK = -1 procedure is called an "LWORK query" and should be
discussed in the LAPACK Users' Guide.
mfh
Olumide
> lets you determine the best LWORK value by setting LWORK = -1 and
> passing in a one-element array for WORK. If the call succeeds (INFO =
> 0), then WORK(1) will have been set to the optimal LWORK value. Then
> you can set LWORK to that value, allocate the WORK array to that length
> and call again.
LWORK = -1?
Olumide
performance penalties? i.e. calling DSYSV twice.
Evgenii Rudnyi
If you look at the code - you have first to follow
http://www.netlib.org/lapack/double/dsysv.f
and then
http://www.netlib.org/lapack/double/dsytrf.f
you see that this query is very fast. So, not every call leads to a real
solve. It is useful to try to read code. Otherwise, it is simpler just
to run a test.
Mark Hoemmen
> If you look at the code - you have first to follow
>
> http://www.netlib.org/lapack/double/dsysv.f
>
> and then
>
> http://www.netlib.org/lapack/double/dsytrf.f
>
> you see that this query is very fast. So, not every call leads to a real
> solve. It is useful to try to read code. Otherwise, it is simpler just
> to run a test.
In fact, all you need for an LWORK query are the problem dimensions;
you don't even need to have allocated the arrays containing the
problem data, because the LWORK query won't touch them. The LWORK
query does some error checking which can save you the trouble of doing
it yourself.
mfh