I know microsoft recommends against linking to the msvcrt.dll, so please spare me from that warning. They do it all the time in their software (like WinDbg) and they won't introduce breaking changes since all VC6 apps link against msvcrt.dll.
Linking against msvcrt.dll has several benefits. Small executable, easy deployment: msvcrt is there since win98 and I don't have to bundle few MB C runtime with my installer.
Now, is it possible to use gcc to link agains the C library in msvcrt.dll instead of glibc? If yes, how?
Thanks!
AFAIK the MinGW port for gcc does link your program to msvcrt.dll.
Related
Currently we build our application with same toolchain as the toolchain used for building root filesystem.
Is it valid to build application with a newer toolchain, or will it result in any mismatches when running on the target filesystem ?
EDIT:
I want to add sanitize checking for application. Unfortunately arm-linux-gnueabihf version 4.8 does not support it yet. So I want to build my application with the same linaro toolchain for same architecture, just more updated (version 6.4 instead of 4.8)
To make this work you require ABI compatibility between your old libraries and your recompiled application. The C ABI is much simpler as the C++ ABI. You won't have problems with the C parts.
For the C++ parts you might have to select the right ABI version via g++ -fabi-version.
For the C ABI, it is a matter of ABI compatibility between the libc versions used. glibc (which is the one used by the Linaro toolchain) is generally safe.
I want to use clang on Windows to compile C code.
I'd like to know if it is in fact a standalone compiler that can do that, or are its aims somewhat different?
I've used it before, but it appears now that is was piggy-backing on top of whatever gcc compilers were lying around (mingw for example).
If I try a fresh binary installation of clang 64-bits (and I hide my mingw/gcc directories), then it can't find stdio.h for Hello World. This is running from directly inside the bin directory (C:\clang\bin). If I unhide mingw, it will compile, but then I get errors like this (one mingw compiler is in c:\win):
c:\win\bin\ld.exe cannot find -lgcc_s
Considering clang is a 438MB installation, you'd think it would have it's own include and library files! I want to use clang in place of gcc.
So, what am I doing wrong? (I've seen a few questions also about the inability to find stdio.h, but they weren't helpful. Surely clang must be able to compile Hello World by itself?!)
You are confusing compiler with linker with standard library.
Clang is a full featured independent compiler. But it does not provides the standard library (the library containing stdio.h). Traditionally, on Unix systems, the operating systems must provide the standard library it uses. But since you are using Windows, it doesn't, and for whatever reason it finds the ones from MingW installed. There are many free implementations of C standard library which are compatible with Clang.
Lastly, ld.exe is the linker, and it also, traditionally, must be provided by the system. There is one linker, lld, that I believe is being developed alongside Clang, but for whatever reason, the packager of the version you downloaded just chose to configure clang to simply call ld.
Clang is a completely separate compiler (written entirely from scratch, using LLVM). You don't need GCC to use Clang, as can be shown in the case of FreeBSD (they completely replaced GCC with Clang/LLVM and don't install GCC in the base anymore for licensing reasons). There are a variety of different C compilers other than GCC, it's just that GCC is the most common.
However, no compiler provides the standard C libraries (GCC provides some weird libraries like the one you're trying to use). C libraries are provided separately, and you need to install C libraries in order to compile any significant C program. The error message saying cannot find -lgcc_s tells me that you're trying to link against some library provided by GCC. In this case, you probably want to install that library by installing GCC (but note that you don't need GCC to use Clang.
It does appear that your version of Clang has been compiled to use GNU's linked ld, not LLVM's linked lld. As such, you'll need GCC's linker (or you can recompile clang to use LLVM's linker, or just compile the object files and use lld separately).
I think you are missing a path variable. After install you must manually add a PATH to the Windows Environment.
I've downloaded a Linux C SDK that comes with a bunch of static and dynamic libraries. The Readme has this to say:
This SDK was compiled with the gcc version 4.5.1 .
You SHOULD NOT mix this SDK binaries with other gcc versions, because
your application will end up in loading two different libcs, which
results in two different heaps. Mixing heaps will lead to application
crashes, when trying to free memory that was allocated by another
heap.
I've never heard of anything like this and a search on the web hasn't turned up any confirmation for it. What I did find, was something about the ABI, but as I understand it, this just means, that the libraries might be incompatible to my GCC version in the sense that they don't run at all. This has nothing to do with libc versions or the heap.
So, is it true what the Readme says? Or, in more general terms: Should I never try to use libraries I downloaded off the internet with another GCC version than the one they were compiled with?
What if I want to use several libraries that were compiled with different GCC versions?
Thanks everyone,
Moritz
It might be due to the optimisations used to build the SDK. Highly optimised binary has more chances of crashing if mixed.
I have the GNU GCC compiler for Windows. I read that it is able to function as a cross compiler.
How do I do this? What command option(s) will produce an shared library that can be used by MacOS/Linux platforms?
You need to build your own cross-compiler, i.e. you need to get the GCC sources and compile them with a desired target-architecture. Then you have to cross-compile all the libraries.
The process is fairly involved and lengthy. The usual GNU makefiles are pretty good at supporting this (through HOST, BUILD and ARCH variables), but if possible you should leave this to a higher-level abstraction. crosstool is one such tool that comes to mind, but I don't know if it's available for Windows.
It's possible that you'll be able to find pre-build Windows binaries of GCC on the internet that target a particular architecture.
I am compiling a C code using the intel compiler. I integrated icc with visual studio 2010. I want to generate an optimized executable which will run on a windows machine. It is actually a virtual machine in the cloud. I don't have a chance to install any redistributable library to the target machine. I want to statically link all the required libraries. How can I do this?
I suppose you meant icl since you're mentioning VS2010/Windows (icc would be Linux/Mac version): just selecting 'Multi-threaded (/MT)' under Project settings->Configuration properties->C/C++->Code Generation should work. It'll cause both MSVC and Intel runtime to be statically linked into app.
But then it also depends which other libraries are you using, it might not work for all. In that case you can check the dependencies with depends.exe (http://www.dependencywalker.com/) and copy them side-by-side with your .exe to target machine.
Try adding -i-static -static-libcxa to the final linkage.
This should force static linking for intel libraries only.
(You can also try -static as littleadv suggested in the comment, but this will produce a huge static executable with no shared libraries at all)
One more note: A simple workaround would be to copy the executable with the required shared libraries (those that do not exist at the host) to the same directory. Then set LD_LIBRARY_PATH=. before running your dynamically linked executable. This will force searching for libraries in the current directory as well as system directories.
EDIT: I just noticed you said "windows machine". The above is relevant to UNIX machines so probably not useful to you. I'll leave it here in case someone needs the information.