mrand not in mingw? - c

I use dev c++ for my c projects,because it's simple for me.I installed it with the mingw extension.Well,I included stdlib.h and made a call to mrand which according to manpages belongs to that header but I got a linker error.I looked in mingw's headers and found no declaration for mrand although the glibc has one in stdlib.Am I missing something?I thought mingw and gcc were the same.If they are different I suppose that there isn't a way to get gcc's full power.Right?Thank you.

mrand is not part of the standard C library, nor is it present in standard Linux manpages. Whatever compiler you previously used may have had it as a proprietary extension, but since you haven't mentioned which (it's not GCC or MSVC, at least), I can't tell what mrand is supposed to do, and so it's hard to suggest an alternative function to use.
Note that glibc does offer a mrand48(). Since this is a POSIX function, not a standard C function, it may or may not be present in other C libraries - but note that this is a function of the C library (glibc), not the compiler (gcc/mingw).

Related

Why do some system libraries require a -l option while others do not?

I recently took a class where we used pthreads and when compiling we were told to add -lpthread. But how come when using other #include <> statements for system header files, it seems that the linking of the object implementation code happens automatically? For example, if I just want to get the header file #include <stdio.h>, I don't need a -l option in compilation, the linking of that .o implementation file file just happens.
For this file
#include <stdio.h>
int main() {
return 0;
}
run
gcc -v -o simple simple.c
and you will see what, actually, gcc does. You will see that it links with libraries behind your back. This is why you don't specify system libraries explicitly.
Basic Answer: -lpthreads tells the compiler/linker to link to the pthreads library.
Longer answer
Headers tell the compiler that a certain function is going to be available (sometimes that function is defined in the header, perhaps inline) when the code is later linked. So the compiler marks the function essentially available but later during the linking phase the linker has to connect the function call to an actual function. A lot of function in the system headers are part of the "C Runtime Library" your linker automatically uses but others are provided by external libraries (such as pthreads). In the case where it is provided by an external library you have to use the '-lxxx' so the compiler/linker knows which external library to include in the process so it gets the address of the functions correctly.
Hope that helps
A C header file does not contain the implementations of the functions. It only contains function prototypes, so that the compiler could generate proper function calls.
The actual implementation is stored in a library. The most commonly used functions (such as printf and malloc) are implemented in the Standard C Library (LibC), which is implicitly linked to any executable file unless you request not to link it. The threads support is implemented in a separate library that has to be linked explicitly by passing the -pthread option to the linker.
NB: You can pass the option -pthread to the compiler that will also link the appropriate library.
The compiler links the standard C library libc.a implicitly so a -lc argument is not necessary. Pthreads is a system library but not a part of the C standard library, so must be explicitly linked.
If you were to specify -nolibc you would then need to explicitly link libc (or some alternative C library).
If all system libraries were linked implicitly, gcc would have to be have a different implementation for each system (for example pthreads is not a system library on Windows), and if a system introduced a new library, gcc would have to change in lock step. Moreover the link time would increase as each library were searched in some unknown sequence to resolve symbols. The C standard library is the one library the compiler can rely on to be provided in any particular implementation, so implicit linking is generally safe and a simple convenience.
Some library files are are searched by default, simply for convenience, basically the C standard library. Linkers have options to disable this convenience and have no default libraries (for if you are doing something unusual and don't want them). Non-default libraries, you have to tell linker to use them.
There could be a mechanism to tell what libraries are needed in the source code (include files are plain text which is just "copy-pasted" at #include line), there's no technical difficulty. But there just isn't (as far as I know, not even as non-standard compiler extension).
There are some solutions to the problem though, such as pkg-config for unixy platforms, which tackle the problem of include and library files by providing the compiler and linker options for a library easily.
the -l option is for linking against an external library in this case libpthread, against system libraries is linked by default
http://www.network-theory.co.uk/docs/gccintro/gccintro_17.html
C++: How to add external libraries

Why C libraries for Linux and Windows are different?

I have tried to run the functions "strlwr", "strupr", "strcmpi", "strrev" from the string.h under Ubuntu and the gcc compiler; getting the next message:
warning: implicit declaration of function ‘strupr’ [-Wimplicit-function-declaration]
as well
(.text+0x84): undefined reference to `strupr'
Once I tried over Windows, same compiler, everything works perfectly.
I looked over the string.h in linux under "/usr/include" which states that was part of the GNU C library ISO C99 7.21 string handling (also tried to compile with the -std=c99, din't work) and I've learned from the header file that I could use the "strcasecmp" function, instead of the "strcmpi".
Can not do the same in Windows (look under the code of the header file) since the headers and libraries files are kind embedded under the compiler code, Am I right?(1)
Again searching for the string.h file in Linux, I have found nearly 50 files with the same name under different paths such as /usr/include/linux;
/usr/include/x86-64-linux-gnu/bits others under the directories of Oracle VB and the Arduino directory.
Why are so many files that handle the strings in C but doing in different fashion? How does the compiler knows which one to take in order to do the work? Is there any way, under the C file or during the compile process to define one of the multiple headers files?(2)
Am I using out of date headers and libraries, Is there any "official" source to know if any library have come depreciated? How to know what are under the Windows headers and libraries?(3)
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5) is what I am using and Windows 8.

Mingw compiling error on Linux with a program made on Windows

I've recently migrated from Windows 7 to Linux (Ubuntu 14.04) and want to compile a C program that I made. The program worked perfectly under Codeblocks 12.11 using GNU GCC compiler's basic settings. When compiling under linux under Codeblocks 13.12 using GNU GCC compiler's basic settings, I get the following error messages:
undefined reference to __mingw_vprintf
undefined reference to __chstk.ms
undefined reference to _fopen
... and so on with fscanf, malloc, etc...
I'm new to Linux and I am not used to C coding, or even programming in general. Does someone have an idea about what's going on?
you have three separate problem going on here.
(1) for _fopen, Microsoft has a nasty habit of renaming all the POSIX functions so they start with an underscore, while your Linux distribution is looking for the standard POSIX name, i.e. fopen. Welcome to the wonderfully frustrating world of cross-platform development :). On solution would be to add something along these lines:
#ifdef __WIN32
#define fopen _fopen
#endif
This in effect says, if compiling on a windows machine (which typically has __WIN32 defined as a preprocessor define; and if it is not you can always make sure that it is) replace every occurrence of fopen with _fopen. The preprocessor will do this for you.
(2) for __mingw_vprintf, I've never seen this function but from the name I would surmise that it is an implementation of vprintf specific to mingw. I personally would rewrite my code to stick with the standard C function vprintf. You can read the manual page for vprintf here; and the MSDN information can be found here. Again notice that many of the Microsoft provide functions have an underscore prepended to the name. You can do something like what you did in case (1) above.
N.B. Actually if I were to rewrite the program I would use C++ IO-streams, but I am sticking to a pure C answers.
(3) for __chstk.ms, again I've never seen this function. My suspicion is that it is something inserted into your code to perform stack checking to help prevent stack-based exploits. To the best of my knowledge there is no way you are going to get that to work on a Linux machine.

Location of built in functions Microchip C30 Compiler

I am asking this just out of curiosity.
I am using Microchip C30 compiler to develop EEPROM driver code for PIC24F.
During this I used C30 builtin functions such as
__builtin_tblwtl(), __builtin_tbloffset etc.
How can I find the location of builtin functions? From Wiki I found this:
"Some compilers (for example, GCC[7]) provide built-in versions of many
of the functions in the C standard library; that is, the
implementations of the functions are written into the compiled object
file, and the program calls the built-in versions instead of the
functions in the C library shared object file"
Does this mean that these functions are written inside the object files of compiler?So does that mean we cannot see it as a code?
I have searched the entire C30 directory and didn't find these functions.
Thank you
user defined functions only stored in objects file of the compiler and above mention functions __builtin_tblwtl(), __builtin_tbloffset etc are previously written in library of Microchip C30 compiler.So you only get link to that library. for example in linux gcc is compiler while glibc are the runtime libraries.

Where can I find the implementation of "time.h"?

Where can I find the implementation of time.h in the C Standard Library, i.e time.c?
I tried with Google Code Search time.c
Is the implementation in the Linux kernel?
time.h is a header from the C standard library.
You will find implementations of the various functions this header provides in the c library implementation of your system.
For instance, the implementation for the difftime function in the libc used for NetBSD can be found in src/lib/libc/time/difftime.c.
For GNU libc, see http://sourceware.org/git/?p=glibc.git;a=tree;f=time;h=c950c5d4dd90541e8f3c7e1649fcde4aead989bb;hb=master
You can find an implementation in the GNU libc library. There isn't a single time.c file. Each function (to a first approximation) lives in its own compilation unit.
Are you actually looking for the implementation of C in the standard library?
Each compiler and OS typically comes with their own implementation (just the headers are relatively standard).
You can see instructions on downloading the sources for GNU C here:
http://www.gnu.org/software/libc/resources.html
time.h is a C standard header, so it describes functions from the C standard library with which it came. For instance, GNU libc

Resources