 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / March 2006error when linking a Fortran library to c++ code in VC8
I get the following error when i try to link a fortran library to a c++ code in .NET 2005. LINK : fatal error LNK1104: cannot open file 'libc.lib' the code was working fine when built using .NET2003. also, when I do not try to link the fortran library (just to see if that was the cause), it builds the exe without any problems. i don't even know how to begin addressing this problem...any help would be appreciated. thanks, Julian. >I get the following error when i try to link a fortran library to a c++ >code in .NET 2005. [quoted text clipped - 7 lines] > i don't even know how to begin addressing this problem...any help would be > appreciated. The singly threaded library you mention has been removed from VS2005. See here: http://msdn2.microsoft.com/en-us/library/abx4dbyh.aspx It should be a simple matter of switching to a multithreaded library to get your project to build. This box does not have 2005 installed, but if you have trouble finding the setting in the project's properties dialog, post again and I'll reply with instructions later on the off chance no one else sets you straight first. Regards, Will > The singly threaded library you mention has been removed from VS2005. See > here: [quoted text clipped - 9 lines] > Regards, > Will thanks for the reply. I see that when I upgraded my c++ project from 2003 to 2005, it automatically made it multi-threaded. but it is the FORTRAN library that is single-threaded. so, I guess I need to rebuild the FORTRAN library with the multi-thread option? in this particular case, that is possible since I have the source code to the library. but what if I was using a third-party library to which I didn't have the source? would I be stuck then ? also, in order to compile the FORTRAN library and get it running with my vc8 code, do I have to use the latest multi-threaded CRTs? or will any version do (this is for rebuilding the FORTRAN library alone)? Julian. > thanks for the reply. You are welcome. > I see that when I upgraded my c++ project from 2003 to 2005, it > automatically made it multi-threaded. OK. > but it is the FORTRAN library that is single-threaded. so, I guess I need > to rebuild the FORTRAN library with the multi-thread option? First the disclaimer: the last time I did any Fortran development on a regular basis I was sitting at an IBM 029 keypunch nachine. I suspect that things have changed a lot since the dark ages. :-) That said, I don't think that you should have to rebuild your Fortran library though I may be wrong. > but what if I was using a third-party library to which I didn't have the > source? would I be stuck then ? The problem of mismatched libraries usually occurs when you try to pass references to objects created in a component built with one library to a component built in another. Passing, for example, C file handles or pointers to blocks allocated with malloc() or the new operator, may bite you, depending on how the callee uses them. I doubt that either the C or C++ runtime is similar enough to that of Fortran to allow this kind of problematic sharing. Of course, I could be wrong. Rather, I think that by using the multi-threaded runtime you will make your application safe for multi-threading. With the single thread I expect that you have, that should be a nit. > also, in order to compile the FORTRAN library and get it running with my > vc8 code, do I have to use the latest multi-threaded CRTs? or will any > version do (this is for rebuilding the FORTRAN library alone)? As I said, I have to duck the Fortran questions because of my lack of experience with it. Whose compiler are you using? And what does your library do? If you post again, someone with Fortran knowledge may pop in. If no one does, you might post again in microsoft.public.vc.language which I think sees a bit more traffic than this group. Regards, Will >> thanks for the reply. > [quoted text clipped - 47 lines] > Regards, > Will actually, I went ahead and rebuilt the fortran library using the multi-threaded option (using Digital Visual Fortran). and it worked ! VC8 linked the files this time with no errors ! thanks for the reply ! > actually, I went ahead and rebuilt the fortran library using the > multi-threaded option (using Digital Visual Fortran). and it worked ! VC8 > linked the files this time with no errors ! Great! Another option that probably would have worked would have been to add /nodefaultlib:libc.lib to your linker options. If you have another fotran library that you can't rebuild, that might be an option for you. -cd > Great! > [quoted text clipped - 3 lines] > > -cd what actually happens when you do that ? does that mean that it will force the fortran library to be a multi-threaded library? also, while i didn't get any errors, i did get this warning: LINK : warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library can you explain that to me? what exactly is the conflict? and will that cause problems for me later on? I used "multithreaded-debug" for the c++ program. and "multi-threaded" in the debug configuration as the 'active configuration' for the fortran library. thanks, Julian. >> Great! >> [quoted text clipped - 16 lines] > "multi-threaded" in the debug configuration as the 'active > configuration' for the fortran library. Object files, regardless of the compiler they're created with, can contain default library requests. These tell the linker to include a particular library in the link even if it's not mentioned specifically in the linker input settings. The /nodefaultlib option tells the linker to ignore default library requests for the named library. If symbols from that library are indeed needed, either the library will have to be supplied explicitly in the linker input settings or some other library will have to supply those symbols for the link to complete without an error. Now, here's the key - the different versions of the runtime library - libc, libcmt, msvcrt and the debug versions of each of those all export the same symbols, with a very few differences. For example, only the multi-threaded libraries contain a definition for _beginthread(). Now, if your code is single threaded (which apparently it is, since you were using the single-threaded libraries with VC6), then it's perfectly safe to link that code against the multi-threaded runtime library. The fact that you're linking a multi-threaded RTL doesn't make your code multi-threaded. It simply means that you're linking with a version of the library that's safe for use by multiple threads - it's also safe for use by a single thread. So, when you re-built your fortran code for multi-threaded, the compiler emitted a default library record requesting libcmt.lib - the static multi-threaded runtime library. Your program was actually linked against msvcrt.lib - the import library for the DLL runtime library. As discussed above, these libraries actually define all of the same symbols. The linker is just warning you that the default library that was specified for your fortran module duplicates symbols that are already in the link and suggests that you use /nodefaultlib to suppress that default library request. In your case, there's no harm in adding /nodefaultlib:libcmt.lib to your linker settings to quite the warning. If you'd rather not have a dependency on msvcr80.dll, you can change your project settings to "Multi-threaded" instead of the default "Multi-threaded DLL" so that your program is linked against libcmt.lib instead of msvcrt.lib. HTH -cd > Object files, regardless of the compiler they're created with, can contain > default library requests. These tell the linker to include a particular [quoted text clipped - 39 lines] > > -cd thanks a lot for taking the time to explain all that. it did help a lot... but i also have some questions: how could you tell that my program was linked against msvcrt.lib? actually, the project settings say "Multi-threaded Debug" and not "Multi-threaded Debug DLL". this is in Property Pages -> C/C++ -> Code Generation -> Runtime Library is there some other place where i need to make this setting? >> Object files, regardless of the compiler they're created with, can >> contain default library requests. These tell the linker to include a [quoted text clipped - 48 lines] > > is there some other place where i need to make this setting? Process of elimination. Since I already knew that you'd changed from using libc, the only other library that would conflict with libcmt is msvcrt. Unless you're mixing debug and non-debug builds anyway! If the fortran module is using libcmt and you're linking it with a debug build, that'd produce the linker warning since your program would be using libcmtd. You can tell which default library(ies) are specified in an .OBJ file by using DUMPBIN /DIRECTIVES {your file here}. Dumpbin is in your Visual Studio tools directory and should be on the PATH if you use the command-prompt shortcut that was installed with Visual Studio. -cd > Process of elimination. Since I already knew that you'd changed from > using libc, the only other library that would conflict with libcmt is [quoted text clipped - 8 lines] > > -cd yeah... u guessed it right... the fortran library was using libcmt.lib , while the program was in debug mode. once i fixed that, the warning vanished. thanks !
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.