|
|
Ublas : |
Subject: Re: [ublas] Linker error?
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-12-15 06:34:51
Mehran Ziadloo wrote:
> You were absolutely right. moddlaed7 indicates a modified version
> of dlaed7 used in the code I were trying to compile.
I shouldn't comment on this. But you should try to avoid these things yourself, because it could cause serious headaches to your colleagues sooner or later.
> I searched the code and found a piece of code written in Fortran
> containing the routine. I compiled it and it's working fine,
> thanks to you. It was my first time compiling some code in
> Fortran and I'm amazed that it's done so easily!
I guess it wasn't Fortran, but an f2c'ed version of dlaed7, with additional modifications written in C. moddlaed7 wouldn't even be a legal Fortran function name, because it has more than 6 characters. And you wouldn't be able to compile Fortran with VC++9.0.
> But still one problem remains that I'm not sure where it comes
> from (Boost Bindings or the other piece of code).
> Perhaps you can help me with this. When I compile and link the
> code in Debug mode, it works fine but when I'm trying to do the same
> in Release mode, it prompts a link error saying it can't find routine __imp___CrtDbgReportW
Maybe the linker option /NODEFAULTLIB:LIBCMTD wasn't such a good idea after all.
> Do you know who's routine this is?
Not exactly. Could be related to std::cerr, caused by including iostream. But it will probably be difficult to avoid including iostream. Anyway, it's more a problem of incompatible build options of your project and the libraries to which you link than a problem of iostream itself.
> And why it can be found in Debug mode and not in Release?!
Debug and release link against different libraries. Often, the debug libraries have a 'd' at the end. So "/NODEFAULTLIB:LIBCMTD" refers to the debug library and "/NODEFAULTLIB:LIBCMT" refers to the corresponding release library. And it's quite easy to end up with inconsistent build options for debug and release in visual studio, if one doesn't pay extreme caution to avoid this (or uses build systems like cmake or boost-build to avoid this sort of trouble).
So instead of linking your release build against
BLASd_nowrap.lib
libf2cd.lib
clapackd_nowrap.lib
you should link it against
BLAS_nowrap.lib
libf2c.lib
clapack_nowrap.lib
> Thanks again Thomas, you are great.
I just wanted to make it clear that it's possible to get it working with visual studio, if one just keeps trying. I have enough experience with visual studio to solve my own problems of this kind, but that's all. Your initial problems where close enough to problems I encountered myself, so I was able to help you. However, all I can offer for your remaining problems is guesswork.
A final remark: I haven't payed much attention to the usage of 'iostream' inside the numeric-bindings up to now. Also, the regression-tests are only run in debug mode by default, and I haven't payed attention to also test whether they work in release mode. Still, I'm pretty sure there are no problems in release mode, because I have set up a VC-project that uses the numeric-bindings library in release mode and links against BLAS_nowrap.lib and libf2c.lib. I admit that it doesn't link against clapack_nowrap.lib, but I don't think that this would expose additional problems.
Regards,
Thomas