I am using log10f function of math.h header file and I need to calculate log value in float that's why I use the above function
I am just posting the sample code instead of the actual code due to confidential information
#include<stdio.h>
#include<math.h>
void main(){
printf(" --->>> %f \n", log10f(4) - log10f(3));
}
Some how I am able to run that code in linux using gcc compiler with following command and it compiled properly and running properly
gcc Demo.c -lm -o Demo
./Demo
But I have to run the project on the windows too and I am using window 7 and turbo c but using tc my program compiled properly but at run time it showing me a LINKER ERROR UNDEFINED SYMBOL _LOG10F
Anyone have any Idea that how can I resolve this issue on Tc at windows.
Suggestions are most welcome thanks a lot in advance.
log10f was added to the C language 16 years ago. You are using a a compiler which is 25 years old, so it won't work.
A work-around might be to use log10 instead, which was available in the C90 standard. It uses double instead of float.
Related
This question already has an answer here:
gcc compiler in Cygwin output .exe
(1 answer)
Closed 5 years ago.
When I compile below "hello_world.c" through cc hello_world.c,
it makes an 'a.exe' instead of 'a.out'
#include <stdio.h>
main()
{
printf("hello, world\n");
}
What is a difference between "a.out" and "a.exe" ?
Why I get an "a.exe" instead of "a.out" ?
That depends on your platform. For example gcc will produce .out on linux, and .exe on windows if you don't give it any additional parameters. (i.e. run cc / gcc "source").
You can force gcc to produce a .out on windows with gcc "source" -o "dest.out".
If your compiler outputs one extension by default (in your case it seems that .exe is the default which is perfectly OK for Windows), I would stick with it. No need to worry about not getting the other type.
Binary executing files in Windows have extension exe. I am not sure about com-files supporting, but it is not our case. Extension out usually uses for writing a text protocol when some program is working. I could guess that it is your program itself, being launched, creates out-file. For more help, provide at least what program environment is used to compile your C-program.
a.out temporary file that is created after compilation of a c program is actually an Object Code for Unix-like operating systems. Object code is used for writing system calls which implements the code functionality and relocation information for linker to help it find the object code in memory(more info here).
Compiler compiles the code and writes a file known as object code and in linux/unix the file is known as a.out.
This file can be further linked to definitions(OR more technically libraries) present in the operating system to form the executable image.
For example in Windows :
I've added a new function wiringPiVersion() to wiringPi, but after I build and install the shared library, when I attempt to compile a small C program around it, I get:
wpi_ver.c:(.text+0xc): undefined reference to `wiringPiVersion'
However, when I include it in an XS based Perl module, all works well. I don't know enough about C to figure out what's going wrong here, and I've been searching for the better part of two hours trying different things to no avail.
Here's my small C program to test the new function:
#include <stdio.h>
#include <wiringPi.h>
int main (){
char * ver = wiringPiVersion();
printf("wiringPi version: %s\n", ver);
return 0;
}
Compilation that throws the error:
gcc -o ver wpi_ver.c -lwiringPi
The addition to wiringPi's header file:
extern char * wiringPiVersion(void);
The wiringPi's .c file addition:
#define WPI_VERSION "2.36"
char * wiringPiVersion(void){
return WPI_VERSION;
}
In my Perl module's XS file, I have:
char *
wiringPiVersion()
...and my Perl module's Makefile.PL
LIBS => ['-lwiringPi'],
...and after re-installing the Perl module, I can access the function without any issues in a test script.
I'm hoping this is something simple I'm overlooking which someone may be able to point out. My question is, how do I rectify this?
So it turned out that there were two .so files generated when I rebuilt wiringPi... one in the wiringPi's build directory way under my home directory, and the other in /usr/local/lib.
After a tip in comments, I added the library path explicitly:
gcc -o ver wpi_ver.c -L/usr/local/lib -lwiringPi
...and it all fell together and works as expected:
$ ./ver
wiringPi version: 2.36
Note: I have sent Gordon the patch in hopes it gets included in the next wiringPi cut.
Update: I received an email back from Gordon and he stated that currently, only the gpio application has the ability to report the version, so he advised that he's going to add something similar to my patch in a future release.
Although already solved, I added this answer to show what gave me the hint.
Error message "undefined reference" points to a linker error (cf. answer on SO), so its about checking if the correct library is drawn.
I am using Code::Blocks 13.12 for programming in C. After building and running my simple HelloWorld.c program, it gives an error.
Error: An alert box pop up saying -"cc1.exe has stopped working.A problem caused the program to stop working correctly.Windows will close the program and notify you if a solution is available."
I tried using Notepad++ , the same pop up appears saying a.exe has stopped working.
I am a naive,so have no idea on how to deal with this.
My queries:
1) Am I using an outdated version? If not, how can I get rid of this problem?
2) Which is the most efficient IDE available for C/C++ if Code::Blocks is not that efficient?
My requirement"
-I had been using Turbo C and it doesn't give errors like segmentation fault and other memory related errors that we get in online Compilers or compilers of competitive programming.So, I need an efficient compiler which behaves same as online compilers, so I don't get stuck while solving problems during competitive programming.
This is the simple code giving error:
#include <stdio.h>
void main()
{
printf("Hello world!");
//return 0;
}
Edit:
Even after changing the code to return int, it's giving an error.I tried editing the code as below, but the same window is being popped up again.
int main(void)
{
printf("Hello world!");
return 0;
}
There's no problem with your code, though indeed, as pointed out in the comments, neither void main() nor int main(void) is considered correct, but that's not what's causing the problem. cc1.exe is a MinGW-related file (MinGW is the GCC port for Windows that Code::Blocks uses by default for compilation); if it's crashing, it's possible the installation is corrupt.
I suggest you try reinstalling MinGW - remove Code::Blocks, install the standalone MinGW version, then download Code::Blocks without the compiler suite, install it and configure to use your version of MinGW.
For me, the solution was to choose,
Select target -> Release
from the Build menu. It took lots of time for me to find this!
I am using MATLAB on the Linux MINT. I have a C program for which I want to used mex command as follows:
mex /home/.../binary.c -output binary_m
but I get the following error
Warning: You are using gcc version "4.8.1-10ubuntu9)". The version
currently supported with MEX is "4.4.6".
For a list of currently supported compilers see:
http://www.mathworks.com/support/compilers/current_release/
/home/.../binary.c:43:19: fatal error: binary.h: No such file or directory
#include "binary.h"
^
compilation terminated.
mex: compile of ' "/home/.../binary.c"' failed.
I think that I have to downgrade the gcc compiler on the MATLAB but I don't know how.
Any help is appreciate it.
Regards
This has nothing to do with the warning regarding the compiler version; don't pay attention to that, you will be fine. You might have had problems trying to compile c++11 sources, depending on your Matlab version, compiler version and mex command flags, but this is not your case.
Here is the problem: your C program binary.c contains an #include statement of the file binary.h which is not found by Matlab (although I trust you put it in the same directory than the C file?) because the directory that contains your C sources is not in the Matlab path.
To fix the problem, simply change directory to where binary.c is, and mex your file there. You can automate the process doing something like:
source_dir = '/home/.../';
current_dir = fileparts(mfilename('fullpath'));
cd source_dir;
% do something
cd current_dir;
Has anyone experienced this sort of problem while attempting to running a executable generated by clang on a code using libclang (it occurs if I compile using gcc too)? Using few prints I noticed that it occurs on the following function call: fprintf(stderr, "%s\n", clang_getCString(String)); There is output from the Cstring in this case. I am compiling using Clang -lclang
Thanks.