[Lapackpp-devel] Re: Lapack++ v2.2 with Visual C++.NET

[Christian S. <sti...@tu...>]

Dear Hong-Ming,

Am Samstag, 30. April 2005 00:12 schrieb Lee, Hong-Ming:
> Could you please give me a hand on my attempt to utilize Lapack++ in my
> Visual C++.NET projects?
>
> I've tried to use the pre-compiled version for Win32 system and failed
> (expected?) due to errors such as:
> unresolved external symbol "public: __thiscall
> LaGenMatDouble::LaGenMatDouble(int,int)" (??0LaGenMatDouble@@QAE@HH@Z)
> referenced in function "public: __thiscall
> LaVectorDouble::LaVectorDouble(int)" (??0LaVectorDouble@@QAE@H@Z)

These are expected. In C++, pre-compiled DLLs and any application can only be 
used together if both have been compiled by the same compiler. Yes, it is 
this way with C++. Really.

Since the pre-compiled DLL has been created with the gcc compiler, the 
pre-compiled DLL can only be used with gcc compiled programs. It is therefore 
expected that this doesn't work with any other compiler. 

> Thus I think I have to recompile and re-build the library.  However,
> instead of reinventing the wheels, I would like to use whatever others may
> have created for the Visual C++.NET platform.  Are you aware of any such
> implementations?  If so, can you give me the contact info?

You don't have to reinvent the wheel. It is absolutely intended that for any 
compiler different than gcc you have to compile the library on your own 
(because of C++). Compiling a library is a totally usual thing to do in 
Open-Source projects. After all, it's all about having access to the 
source...

Did this work? If you encounter any compiling problems with other compilers, I 
would happily try to fix these problems. But the compiling itself can't be 
avoided. I think there is a project file for Microsoft Visual C++ compiler 
(version 7) included, but I think it hasn't been tested for a long time. 
Anyway, it should be almost ready still.

And in any case, please discuss problems related to Lapack++ only on the 
mailing list lap...@li..., not with individual 
developers.

Regards,

Christian