When compiling an empty c program using MinGW the assembly output contains the line
call __main
what library is this from? I expected linking with msvcrt.dll to work (linking using ld), but as it did not, it must be define elsewhere.
There are many related/practically the same question elsewhere, but none of them (as far as I have seen, been searching for a while now) actually contain the answer to this question, so please double check before marking as duplicate.
__main should be provided by the libgcc library, which comes with the MinGW compiler.
If you use the compiler driver (that is, the gcc command-line tool) to link your program, rather than invoking ld directly, this library should be automatically added to the link. Using the compiler driver to link is recommended practice for this and several other reasons.
Depending on exactly which version of MinGW you have and which version of GCC it embeds, libgcc or part of it may be a DLL, which you must bundle if you are shipping MinGW-compiled executables.
On my Windows 10 machine, it is in \Program Files\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\lib\gcc\x86_64-w64-mingw32\8.1.0\libgcc.a which is then linked directly with the executable, so you do not have to include any DLL with you software.
Related
I have a publicly-available FMU for which I am trying to link the embedded .so file with the rest of my program. (This is contained within the .fmu file if you view as an archive.) During the linking phase I am getting the following undefined reference errors:
RoomHeating_OM_RH.so: undefined reference to '__longjmp_chk#GLIBC_2.11'
RoomHeating_OM_RH.so: undefined reference to '__fread_chk#GLIBC_2.7'
If I look at the content of RoomHeating_OM_RH.so with a tool like nm -a, I see lots of undefined references of this form that aren't causing errors at link time. Here are a couple such lines from the nm -a output:
U __vsnprintf_chk##GLIBC_2.3.4
U _setjmp##GLIBC_2.0
However, the ones that are causing errors are differentiated from the rest of them by the fact that they have newer versions of GLIBC in the name. Here's what I have in my /lib dir for the libc library (yes I realize these are old versions, but it's what I am stuck with for now):
/lib/libc-2.5.so
/lib/libc.so.6
So my guess is that I don't have a new enough version of libc to link against. Is it a requirement that the version of libc be exactly what the .so file calls out? Or does it only need to be equal to or newer than the version called out? Furthermore, does the FMI specification even cover this aspect of compatibility? Or does it assume that IF .so files are provided in the FMU that they MUST be compiled using the same or older versions of libraries as will be installed on the target machine?
So my guess is that I don't have a new enough version of libc to link against.
Correct.
Is it a requirement that the version of libc be exactly what the .so file calls out?
No. You need GLIBC-2.11 or newer. See this answer for explanation.
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 am trying to use SSE4.2 intrinsics with clang/llvm but its not compiling, as I get cannot select intrinsic error from LLVM. On the other hand, the same code compiles flawlessly in gcc. So I thought, maybe I can compile that function with gcc, so as to have an object or library file, and then call that library function in my code, which is compiled by clang/llvm. Would that work?
It's possible to compile an object file with GCC in Linux and convert it to work in Visual Studio. I did this recently running Linux in Virtual Box on Windows converting-c-object-file-from-linux-o-to-windows-obj so this should be possible with Clang on Linux or Windows as well.
So not only can this be done cross compiler it can be done cross platform.
You need to get the calling conventions and the object file format correct (and for C++ the name mangling as well) . With GCC when you compile you can tell it which calling convention/API to use with mabi. Then, if going from Linux to Windows, you need an object file converter to convert from e.g. ELF on Linux to COFF on Windows. Of course, there are cases this probably won't work (e.g. if the module relies on a system call that is only in one platform). See the link above for more details.
For any more-or-less complicated c++ code, e.g., one that compiles to vtable - the answer is a resounding NO. The two are NOT compatible.
To illustrate the above point, try to compile the Crypto++ library with g++ (gains about 40% speedup for AES/GCM) and then link your clang++-compiled code with it.
It may or it may not work. Some elements of the ABI can be expected to be the same. For example, I believe both g++ and clang use the Itanium ABI name mangling scheme. Others elements can not. So it depends on how complex the code you're compiling is.
Also, I would suggest opening an LLVM bug for the intrinsic that could not be selected. Clang and LLVM have a very active community, and it's possible someone will pick the bug up quickly.
I am developing a bare metal C applications on an ST ARM-Cortex-M3. I have also developed libraries that are usable across all these applications.
I used to use Keil ARM-MDK, but want to move over to GNU-GCC. I thus downloaded the latest version of GCC and started recompiling the code.
Although similar questions to this one have been answered, it does not solve my problem ans therefore I am posting my question.
I have a problem with the following:
Lib_Flash has a function Read_Flash(). Lib_AppCfg links in Lib_Flash as it uses Read_Flash().
My application (App) links in both Lib_Flash and Lib_AppCfg. App also uses Read_Flash() for some specific FLASH checks.
In Keil MDK-ARM it worked fine.
With GCC, when functions using Lib_AppCfg are built, I get errors stating that Read_Flash() is an "undefined reference".
I am not sure where the problem lies. Is it in the linking of the Lib_Appcfg is built or is the problem when I link App?
Please advise. If you need additional information, please let me know.
The GNU linker by default searches the libraries once in the order listed on the command line. So if a library later in the list has a reference to symbol defined in an earlier library or object file, then it cannot be resolved.
The simple solution is to use library grouping; this causes the linker to repeatedly search a list of libraries until no further synbols can be resolved. If you are invoking the linker (ld) separately, then the linker options are:
--start-group _Flash _AppCfg --end-group
or the alternative form
-( _Flash _AppCfg -)
See the GNU linker manual for details. If driving the linker indirectly through gcc you pass linker options via the -Wl option, something like:
-Wl,-(,_Flash,_AppCfg,-)
I think.
It sounds to me like you have got an ordering problem in your libraries. Some linkers will rescan all the libraries on the command line till all references are resolved (or can't be resolved). Other linkers work sequentially along the link line.
In particular, this means that if library A defines a symbol SYM_A and library B which comes after library A references this symbol, it won't be resolved on the 2nd type of linker, and your link will fail.
To get round this, you can do one or more of the following
Reorder the libraries
Replicate libraries on the link line where
necessary
Refactor your libraries so there aren't mutual
dependencies between them (that is A references symbol SYMB, which
is defined in B, but B references SYMA)
I downloaded the glibc source code, modified some portion of the standard library and then used LD_PRELOAD to use that modified standard library (in the form of an .so file) with my program. However, when I copied that .so file to another computer and tried to run the same program using LD_PRELOAD there, I got a segmentation fault.
Notice that both computers have x86-64 processors. Moreover, both computers have gcc 4.4 installed. Although the computer in which it is not running has also gcc 4.1.2 installed besides gcc 4.4. However, one is running Ubuntu 10.04 (where I compiled), while the other is running CentOS 5. Is that the cause of the segmentation fault? How can I solve this problem? Notice that I don't have administrative rights on the computer with CentOS 5.
When you LD_PRELOAD the C library, I believe you're loading it in addition to the default C library. When they're the exact same version, all the symbols match, and yours takes precedence. So it works. When they're different versions, you may well have a mix, on a per-symbol basis.
Also, the NSS (name service switch, e.g., all the stuff from /etc/nsswitch.conf) API is not stable. These modules are separate from the main libc.so, but are dynamically loaded when a program e.g., does a user id to username mapping. Loading the wrong version (because you copied libc.so over) will do all kinds of badness.
Further, Ubuntu may be using eglibc and CentOS glibc. So you could be looking at a different fork of glibc.
If your LD_PRELOAD library included only the symbols you actually need to override, and overrode them to the minimum amount possible (e.g., if possible, call the overridden function), then your library has a much higher chance of being portable.
For an example of how to do this, see (for example) fakeroot.
If you're changing so much of libc that your only choice is to override all of it, then (a) you're doing something very weird; (b) you probably want to use LD_LIBRARY_PATH, not LD_PRELOAD; see the ld.so(8) manpage for details.
It is likely that your libc is not portable between kernel versions.