In Microsoft visual c++ compiler, you can specify linker options using
#pragma comment(lib, "MSVCRT") //links with the MVCRT library
see this page
I find this feature very useful because linker errors are common and i want to just place all the linker options in my source code instead of specifying them to the compiler.
question: Is there a way to do this in gcc (or dev-cpp or codeblocks ide)?
Thanks in advance.
GCC doesn't support this because to link correctly, the order in which you link your objects matters.
See also my answer and others in the question "#pragma comment(lib, “xxx.lib”) equivalent under Linux?"
In short, GCC does not support specifying libraries to link in the source code.
If your IDE handles the compilation and linking process, you can probably add references in your IDE and have it worry about passing the correct options to gcc for each unit.
Given that link options and library names vary very much from system to system, I am quite glad to have them separated from my source code files and thus can keep the source code system independent.
Then the build system can decide how to build on what system. Much cleaner approach overall, I'd say.
Related
In Visual C++, one may link to a library in the code itself by doing #pragma comment (lib, "libname.lib"). Is something similar possible in g++?
The Boost Config library has some support for autolinking, using the relevant compiler-specific code for the particular compiler. However, the docs note that the GCC toolchain doesn't support autolinking:
Auto-Linking
Most Windows compilers and linkers
have so-called “auto-linking support,”
which eliminates the second challenge.
Special code in Boost header files
detects your compiler options and uses
that information to encode the name of
the correct library into your object
files; the linker selects the library
with that name from the directories
you've told it to search.
The GCC toolchains (Cygwin and MinGW)
are notable exceptions; GCC users
should refer to the linking
instructions for Unix variant OSes for
the appropriate command-line options
to use.
Not sure if this is the right place to ask but here goes
From a page on the Intel website, it states:
The Intel C++ Compiler for Windows uses the Microsoft Visual C++ header files, libraries and linker. Microsoft controls the header files that define the namespace. Contact Microsoft's technical support in reference to Microsoft's conformance to the C++ standard on this issue... link
Is there a guide by Intel (or otherwise) to change the libraries from the ones governed by visual studio to ones provided by gcc (Also on my windows machine). the reason I want to do this is to make use of some of the new C++11 features that are not supported in versions of visual studio (as is generally the case)
If this is not possible because my current knowledge of the above is not correct, can somebody explain to me why not.
Thanks.
This is not a practical possibility.
The intel compiler (icl) will do nothing but moan if it cannot find VC++ binaries on the PATH, so you know it needs the VC++ toolchain at least.
Then to see what you are up against, as far as using the gcc headers is concerned, you would do the following:
Make icl suppress its own predefined macros.
Make it use gcc's predefined macros.
Make it suppress its standard include search.
Make it use gcc's standard include search.
None of this is hard, and when you have done it all and attempted to build your HelloWorld.cpp, the errors
will show you that the gcc headers are replete with builtin keywords of the gcc compiler that are
unknown to icl: __builtin_va_list, __attribute__, __cdecl__, __nothrow__ and so on.
You might attempt to successfully delete or redefine all of these by way of preprocessor macros.
Or you might give up, and I would urge the latter.
i want to use gtksourceview in my c++ project. I dig around the IDE of code::blocks and really find it helpfull. i specify gtkmm directory in linker and include options but as i look for gtksourceview i found a libgtksourceview-2.0-0.dll file i really don't know how to add this in code::blocks and use gtksourceview. I am have programming experience in C for microcontrollers just and now i have not really idea about the compilation process of gcc and g++. and can i able to add the file directives as
#include <gtksourceview/gtksourceview.h>
please help
sorry if it seems so basic question for someone but i really stuck of to compile the code and then asking.
I am using windows by the way.
Thanks in advance
There are two different things: the runtime libraries and the development headers. The former allows you to run the applications (also to link them), the later to compile them. Either you are missing the header files (gtksourceview.h in your example) or setting the PATH in your IDE to find the header files.
Check the manual for 'Including libraries'.
Like the msvcr70/msvcr80/msvcr90.dll, what's the code like to instruct the linker to link to one of them dynamically?
Or has that anything to do with c/c++,but cmake?
The specific examples you give happen to be DLLs that are usually linked through manifests and the side-by-side, at least when building applications (with the correct project settings) from Visual Studio. Why are you trying to instruct the compiler to link them by code?
The most often-used way to link to a particular DLL is when you have the lib for the DLL available, and then to use the pragma
#pragma comment(lib, "<library name>")
You specify a .lib file when you link, and the matching .dll will be used at run time, so (for example) if you want to use msvcr70.dll, you'll want to link with msvcr70.lib.
In general, the C/C++ runtime you link against is dependent to the version of VisualStudio you are using. (msvcr80.dll -> VS2005, msvcr90.dll -> VS2008 etc.)
Some deeper insight on how this works and some tricks to work araoud this you can read up in this blog post.
eh, surely you want to first understand DLLs/linking... http://www.infernodevelopment.com/how-create-dll-c-using-run-time-dynamic-linking
the question as written is not answerable
Note: not sure what you mean with Cmake, but you can easily specify link libraries in your CMakeLists.txt file... the exception being the DLLs you note, because they are platform-dependent. You'd need something in the CMake script to check versions of MSVC.
Why would you want to link to an older run-time though, Vista onward come with the VC9 run-time, and if someone is using XP you can just give them the 'redistributable package' for VS2008/2010...
I am trying to build a dll using mingw g++ under cygwin.
I have .h files that refer to objects exported by a .dll that was build using MS Visual Studio 2008. I link to the .lib generated with that .dll.
When I run g++ I get lots of errors like this
/cygdrive/c/dev/blox/ulfx/ulfx/JavaInterface.cpp:206: undefined reference to `__imp___ZNK18DLLSafeDoubleArray4sizeEv'
The .dll that I want to link to exposes a function named
?size#DLLSafeDoubleArray##QBEIXZ
And I assume that the problem here is that the g++ name mangling is incompatible with the VS2008 name mangling.
Is there a way I can force g++ to use a compatible mangling ?
I do not have any version of Visual Studio installed on my machine.
G'day,
Not sure if this is going to be possible as there is too much that can vary between compilers from different vendors apart from just the name mangling. Things such as:
this handling,
layout and contents of v-tables,
class layout,
parameter sequence,
register handling,
return value handling,
etc.
I'd be interested to see if it was possible though.
Maybe this page helps:
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
I did manage to do something once but it was just a prototype which I abandoned when I found a library doing what I wanted. I did follow their instructions though, but I was producing the dll myself.
I agree with Rob Wells comment, there are a lot of things in C++ that may break.
Something which should be easier, safer, and possible would be to use plain C functions, as the main thing to worry about there is the calling convention and potentially packing and alignment of structs.
Object code produced by different C++ compilers is not link compatible.
This is done on purpose: compilers use different ABI, and if the name maingling didn't prevent you from linking, you'd now be wondering/debugging why the simplest operations are causing your executable to crash.
You should be grateful that the different name mangling scheme spared you that debugging effort.
Better way is to recompile dll with g++. If it is possible.