I am failed to compile builtin example hwserver.c using ZeroMQ APIs. I have tried every possible way.
gcc -lzmq hwserver.c -o hwserver
It prompts me with:
hwclient.c:(.text+0x22): undefined reference to `zmq_ctx_new'
hwclient.c:(.text+0x3a): undefined reference to `zmq_socket'
hwclient.c:(.text+0x52): undefined reference to `zmq_connect'
hwclient.c:(.text+0x94): undefined reference to `zmq_send'
hwclient.c:(.text+0xb8): undefined reference to `zmq_recv'
hwclient.c:(.text+0xe4): undefined reference to `zmq_close'
hwclient.c:(.text+0xf0): undefined reference to `zmq_ctx_destroy'
collect2: error: ld returned 1 exit status
I'm using zeromq-3.2.2 on ubuntu-12.10
Any help really appreciated.
Thanks,
-Sam
Order of arguments to gcc does matter a lot.
Try
gcc -Wall -g hwserver.c -lzmq -o hwserver
You need first the warning and optimizations or debugging flags (e.g. -Wall for all warnings, -g for debugging information), then the optional preprocessor flags (like -D or -I but you have none of them), then the source files, and at last the libraries -lzmq (order is relevant: from high level libraries to low level ones) and the output option -o hwserver (which could be elsewhere).
Read the gcc documentation, notably the chapter about invoking GCC.
Don't forget the -Wall : you really want to get all warnings, and you should improve your code till no warnings are given. You could even want -Wextra to get more extra warnings.
Don't forget the debugging information flag -g: you will need to use the gdb debugger to debug your program.
Later, use -O or -O2 to optimize the binary program (the compiler will then produce more efficient, but less debuggable, machine code). Care about that only when your program is debugged.
As soon as you want to develop real-sized C programs (i.e. your project made of several source files and some header file[s]), you'll need a builder infrastructure, like GNU make (a very common builder; you could try omake instead).
See also this answer to a related question.
try again
gcc hwserver.c -o hwserver -lzmq
Your order of the parameters is incorrect.
Related
I wanted to compile the below code in VS Code, but I'm fetching this error using "code runner". I've looked up everywhere, but it didn't solve my issue.
I want to implement this T(n) = 2T(n/2) + nlog(n)
q2.c
// b. T(n) = 2T(n/2) + nlog(n)
#include <stdio.h>
#include <math.h>
int func(double n)
{
return (2*func(n/2) + n*(log(n)));
}
int main()
{
double n, result;
printf("Enter the value of 'n' \n");
scanf("%lf",&n);
printf("Hey");
result = func(n);
printf("%lf \n",result);
printf("Hey");
return 0;
}
Console:
user#user-H310M-DS2:~/Desktop/C programming/Assignments$ cd "/home/user/Desktop/C programming/Assignments/" && gcc q2.c -o q2 && "/home/user/Desktop/C programming/Assignments/"q2
/tmp/ccnNXN3L.o: In function `func':
q2.c:(.text+0x3a): undefined reference to `log'
collect2: error: ld returned 1 exit status
Visual studio code has nothing to do with your issue, you are not compiling with it. Because it is an IDE (or source code editor), not a compiler. I guess you are using it on some Linux or POSIX system. BTW my preferred source code editor is GNU emacs. So your IDE is running some compilation commands (and you need to understand which ones and what these commands are doing). You could run these commands in a terminal (and that actually might be simpler).
As your console logs shows, you are compiling with GCC. Some gcc command has been started (by Visual studio code probably).
Read carefully about Invoking GCC. Order of arguments matters a lot!
You should compile your code with
gcc -Wall -Wextra -g q2.c -lm -o q2
Let me explain this a bit:
gcc is your compiler front-end (the actual compiler is cc1 but you never use it directly; you ask gcc to run it)
-Wall asks for almost all warnings
-Wextra asks for extra warnings. You'll be happy to get them
-g asks for debugging information in DWARF. You really want to be able to use the gdb debugger, and gdb practically needs debugging information.
q2.c is the source file of your sole translation unit
-lm is for your math library. You are using log(3) and its documentation mention that.
-o q2 tells gcc to put the executable in q2 (the actual work is done by the ld linker invoked by gcc)
How to configure visual studio code to use that command is your business. You could otherwise type the above command in a terminal. Then you can run your q2 program by typing ./q2 in a terminal for your shell (and you could use gdb on it).
Notice that gcc is starting other programs (like cc1, as, ld). If you want to understand which ones, insert -v after gcc in the command above.
Be sure to read the documentation of every function you are using (so read printf(3), scanf(3), log(3) at least...) and of every program you are using (e.g. of gcc and of Visual studio code).
Once you'll write bigger programs made of several translation units (e.g. foo.c, bar.c, gee.c), you would want to use some build automation tool (because compiling all of them every time with gcc -Wall -Wextra -g foo.c bar.c gee.c -lm -o qqq is possible, but inconvenient). You could learn to use GNU make (or ninja).
Read How to debug small programs. Don't expect your program to work as you want at first.
BTW, study the source code of some existing free software programs (but start with simple projects, e.g. on github, of less than a hundred thousand lines). This could teach you many useful things.
I'm not sure how VSCode compiles programs, but since it uses GCC, it's likely that you need to link the math library libm when compiling, by supplying an argument -lm to GCC.
Just a tweak to code runner's settings.json under file->preferences->settings of VS Code :
I've added the below line
"code-runner.executorMap":
{
"c": "cd $dir && gcc -Wall -Wextra -g $fileName -lm -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
}
It's working now.
This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Closed 2 years ago.
Im currently writing a program for a uni asssessment and they have a set line to compile it, so if it doesn't work with that it won't be accepted.
They command they use is
gcc -Wall -ansi -lm program.c -o program.out
My program will not compile that way, and it'll give me a undefined referance error (Referring to my log10 using math.h library)
if i use:
gcc -Wall -ansi program.c -o program.out -lm
it works
What could be my issue?
Im using windows 10 64bit and have windows bash installed and gcc.
This would be explained if your instructors are using gold and you are using GNU ld. These are two linkers, both are part of the GNU project, and both are commonly used with GCC.
If you are using GNU ld, you get the "traditional" behavior:
The order of specifying the -L and -l options, and the order of specifying -l options with respect to pathname operands is significant.
This means that you have to put -lm after any object files and libraries that depend on it.
However, if you are using gold, the -l options may appear first.
If you have gold installed on your system, you can test it yourself.
Here is what I get:
$ gcc -lm program.c
/tmp/ccJmBjmd.o: In function `main':
program.c:(.text+0x15): undefined reference to `sin'
collect2: error: ld returned 1 exit status
But if I use gold, it works fine:
$ gcc -lm program.c -fuse-ld=gold
-lm needs to be at the end of the command, most likely in the first case with the literal the compiler is optimizing out the call to any function and therefore does not need to link against the library. This is called constant folding and for example we can see in the gcc docs on Other Built-in Functions Provided by GCC says:
GCC includes built-in versions of many of the functions in the
standard C library. The versions prefixed with __builtin_ are always
treated as having the same meaning as the C library function even if
you specify the -fno-builtin option. (see C Dialect Options) Many of
these functions are only optimized in certain cases; if they are not
optimized in a particular case, a call to the library function is
emitted.
I'm trying to debug an issue where the wrong version of a function gets called causing a segfault. The code that I'm compiling is machine generated and includes a function called 'times' that does a complex multiply of it's two arguments. This code is compiled to a .o before being linked into a higher level object file.
When run this code segfaults and gdb indicates that it's in glibc's version of 'times' which doesn't even take the same number of arguments. The are no instances of '#include anywhere in this code.
Changing the name of times to times1 resolves the problem. This isn't a long term solution though due to the machine generated nature of the code and manually editing the name of this function all the time is unappealing.
The whole mess compiles cleaning with -Wall so I'm not sure where to look. Any ideas on how to resolve this?
Compile chain:
gcc -Wall -I. -g --shared -o dpd.o -fPIC *.c (mahine generated code here)
gcc -g --std=c99 -c -fpic getData.c -I/usr/local/include -L/usr/local/lib -lmatio -I/usr/local/include/iverilog -I$(MATLAB)
gcc -g -shared -o getData.vpi getData.o $(MATLAB)/dpd.o -lvpi -lmatio -L/usr/local/lib
C only uses the name of a function as an identifier, so any two (exported) functions with the same name will conflict. The normal approch is to prefix all exported names in a library with a unique prefix. The other alternative is to use C++ as "a better C" and simply build your C code using a C++ compiler, making use of C++ name mangling.
So the real answer to this one is to throw -fno-builtin-times to gcc. That avoids the problem neatly with no fuss.
This of course assumes that you can't changes the name of times to something that doesn't conflict with a glibc provided function.
How can I know in which step (Pre-Processor,Compiling, Linking) my program got compilation failure?
For example, I wrote a program of 3 source files: a.c ,b.c, c.c and all three of them included the header file, h.h, which contains all the prototypes of all the source files, but I also implemented one function, in the header file. I know it's wrong to do, but I wonder on what stage did the program crash, Is it the linking or the compiling, I got an error message, Is this say that the problem is at the linking stage? (otherwise I'll just get a red underline on the mistake from the compiler?)
Where can I read about linking and what I shouldn't do regarding headers and source files and linking errors?
(I work in Linux, with Eclipse)
You find the location of the error by separating compiling and linking. An error due to the precompiler is unusual and also found during compiling. This is how compiling works on the command line:
Compile step:
gcc -c -o a.o -pedantic -Wall a.c
gcc -c -o b.o -pedantic -Wall b.c
gcc -c -o c.o -pedantic -Wall c.c
link step:
gcc a.o b.o c.o -o prog
Of course you need to specify whatever other flags that are necessary (e.g. -l for linking to a library etc.)
Then read the errors and warnings (!) carefully and you shall find the problem.
Your program crashes only once you have pre-procesed, compiled and linked your program to generate an executable that you can run. A crash is a run-time error.
Re preprocessor/compilation/linking:
You didn't specify what platform/environment you are working in, but in a Linux/Unix environment it is easy to determine if you are getting problems with the linker as you usually get a message with ld.
Compilation errors usually syntax related and easy to identify that way (e.g., mismatched parens, missing semi-colons, etc) (Aside, as a general rule, I would recommend you always compile with the highest warning level, and then consciously determine which warning messages to ignore.)
I am not at a system were I can try it out, so I'm not sure of the pre-processor throws out specific easily identifiable error/warning messages, or if they just get passed on to the compiler and get spit out at that stage.
None of these steps crash your program, that only happens (if it does) after all these steps have been completed successfully.
I'm trying to build GCC for use with an AVR microcontroller and avr-ada, and I've hit a roadblock caused by my regular compiler being too picky about the version I needed for the AVR. I get the following warning, which in turn causes GCC or Make to report an error:
gcc -c -g -O2 -gnatpg -gnata -nostdinc -I- -I. -Iada
-I../../gcc/ada ../../gcc/ada/exp_ch5.adb -o ada/exp_ch5.o
exp_ch5.adb:177:16: warning: function "Has_Address_Clause" is not referenced
make[2]: *** [ada/exp_ch5.o] Error 1
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2
Is there a way to instruct GCC or Make to not fail on warnings?
Try make -k instead of just make. That will 'continue' rather than stop.
As an alternative to diving into the build system, try setting -Wno-error in CFLAGS, which you should be able to do through the environment (or at configure time, if using the GNU build system).
The trigger here is the -gnatpg (actually, the -gnatg): this is the "GNAT implementation mode (used for compiling GNAT units)". -gnatp means "suppress all checks".
I'm not sure of the full effect of -gnatg, though it certainly causes warnings to be treated as errors -- like -Werror -- at any rate while building the compiler itself; I think I remember seeing non-fatal warnings while building the RTS.
One possibility would be to compile just exp_ch5.adb by hand without -gnatg; the command you list was issued at gcc/, so
$ cd gcc
$ gcc -c -g -O2 -gnatp -gnata -nostdinc -I- -I. -Iada -I../../gcc/ada \
../../gcc/ada/exp_ch5.adb -o ada/exp_ch5.o
Then back up one level, and 'make' again.
This is a cross-compiler, so you won't (I hope!) need to repeat this for all three stages of a full build.
It seems the -Werror flag is set in the Makefile. Maybe you can look for the CFLAGS options in the Makefile and remove the -Werror flag. The Werror flag will make all warnings into errors.
In general, it is not a good idea to ignore warnings from your compiler. However, if this is a portion of a larger make process there is likely a -Werror flag inserted earlier in the sequence. Start by looking for that.
After looking around, there seems to be a wealth of flags to control warnings while compiling Ada code. For instance, -gnatwF will Suppress warnings on unreferenced formals according to this guide. Possibly the switch you require can be found in the list provided there.
In gcc configure you can add --disable-werror.
Though it's advisable to seek out a proper patch first.
Put "pragma warnings(off, "...")" into the offending parts of your code.
See http://www.adacore.com/2007/11/19/ada-gem-18/.