I am using sin function in one of my c program.
The program runs prefectly on fedora machine but ginving reference issue in ubuntu machine
I have compile it using -lm like following:
gcc -lm kepler.c -o a.out --working on fedora, but not on ubuntu
gcc kepler.c -lm -o a.out --Working on both, fedora and ubuntu
/tmp/ccshH33a.o: In function `kepler':
/tmp/28/kepler.c:7: undefined reference to `sin'
collect2: error: ld returned 1 exit status
So can any one explains about the position of -lm, and why its working on fedora machine for both cases?
Thanks in Adavance.
gcc like all common compilers internally launches different programs : at least a compiler and a linker. -lm option is intended for linker, as is -o a.out. BTW,-o a.outis just a no-op sincea.outis the default name when-o` option is absent.
Why -lm before kernel.c may fail : as explained in the answer to the question referenced by Cornstalks in comment, linker processes its arguments left to right, so dependant libraries must come after modules calling them
Why could it succeed on fedora : object modules will always be included in the executable program, so it can makes sense to always put them first in the argument list passed to the linker, of for the linker to process them first
Why did it work on Fedora and not on Ubuntu : I assume it is not same version of gcc, and the one on Fedora is more tolerant.
Anyway, the correct way is to always put dependant libraries after the modules (or other libraries) calling them.
Related
Based on This Stackoverflow link I downloaded & installed glibc v2.29 in "/usr/local/glibc" path of Linux OS. Then based on this Stackoverflow link I tried to compile This Example, But I got following errors.
First Try Command:
gcc -Wall -g -o main main.c -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
First Try Error Log:
main.c:1:10: fatal error: threads.h: No such file or directory
#include <threads.h>
^~~~~~~~~~~
compilation terminated.
Second Try Command:
In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
Second Try Error Log:
/tmp/ccCNYemW.o: In function `main':
/home/.../main.c:14: undefined reference to `thrd_create'
/home/.../main.c:16: undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
So I don't know where is the problem. Please Help me.
First of all, don't put an alternate libc (or alternate version of your libc) in a path searched by the normal include and library search (both link-time and runtime library search) for your main system one. This is a recipe for disaster. Installing a different glibc in /usr/local/ does avoid clobbering your system one, but now you just have two installed in places where the same tools can see and use them.
To do this right, you really need a full separate toolchain (gcc, binutils) in some completely separate path (like ~/my_glibc_root/... or /opt/alt_glibc_root/...). I'm not sure if there's a recommended way to do this. The glibc build procedures in Linux From Scratch might be a good place to look for ideas. In theory it can be done in a single stage; I do that with musl libc in musl-cross-make by careful use of intermediate make rules in the gcc build system. But applying the same idea to glibc probably requires some extra care.
Second Try Command: In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
This command is almost correct. The thrd_create and thrd_join functions are defined in libpthread, which you didn't link against.
Add -pthread to your compile command, and the link should succeed.
P.S. R's advice of not installing alternate GLIBC into /usr/local is also a good one.
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 am writing an application that has multiple subdirectories. I have created a Makefile structure such that the subdirectories compile the file and do "ar rvs" and "ranlib libxxx.a" to create archives into the parent directory for linking.
However the "ld" command is running into the following problem.
ld: warning: ignoring file ./libxxx.a, file was built for archive which is not
the architecture being linked (x86_64):
./libxxx.a Undefined symbols for architecture x86_64:
I am using gcc on Mac OS X 10.10.1
I read many posts on this. I tried "gcc -arch i386", then I encounter the same error for i386
Undefined symbols for architecture i386:
I installed gcc-4.9.2 and tried using it instead of the default gcc, with no luck. I tried using x86_64-apple-darwin14.0.0-g++-4.9.2 and that did not help either.
The errors you are seeing mean that you have a mixture of i386 and x86_64 code in the build, and you need to be consistent. Unless there's a compelling reason to do otherwise (I'd be curious to know what it is), you should be compiling everything for 64-bit only. Using gcc on Mac, that is normally the default, but you can force it by adding a -m64 flag to the compilations. One way of doing that is to set CC="gcc -m64" on the make command line; there are other better ways too, but the details depend on your makefile contents.
To resolve: first, remove all the libraries and object code you've built in your project area (maybe make clean will do it — if you wrote a clean target). Then, fettle the value of CC or its flags (CFLAGS ultimately, but how CFLAGS is built depends on the makefile) so that 64-bit compilation is enforced. Then make sure you're using that in all compilations. If you don't see the -m64, you've got a problem.
If you must use 32-bit, substitute -m32 for -m64.
The discussion above assumes you are using gcc to run the ld command. If you are not, then you're on your own until you use gcc to run the ld command. In my view, you've got better things to do with your life than work out how to run the ld command correctly; I certainly have.
They say that main() is a function like any other function, but "marked" as an entry point inside the binary, an entry point that the operating system may find (Don't know how) and start the program from there. So, I'm trying to find out more about this function. What have I done? I created a simple .C file with this code inside:
int main(int argc, char **argv) {
return (0);
}
I saved the file, installed the GCC compiler (in Windows, MingW environment) and created a batch file like this:
gcc -c test.c -nostartfiles -nodefaultlibs -nostdlib -nostdinc -o test.o
gcc -o test.exe -nostartfiles -nodefaultlibs -nostdlib -nostdinc -s -O2 test.o
#%comspec%
I did this to obtain a very simplistic compiler and linker, no library, no header, just the compiler. So, the compiling goes well but the linking stops with this error:
test.c:(.text+0xa): undefined reference to '___main'
collect2.exe: error: Id returned 1 exit status
I thought that the main function is exported by the linker but I believed that you didn't need any library with additional information about it. But it looks like it does. In my case I supposed that it must be the standard GCC library, so I downloaded the source code of it and opened this file: libgcc2.c
Now, I don't know if that is the file where the main function is constructed to be linked by GCC. In fact, I don't understand how the main function is used by GCC. Why does the linker need the gcc standard libraries? To know what about main? I hope this has made my question quite specific and clear. Thanks!
When gcc puts together all object files (test.o) and libraries to form a binary it also prepends a small object (usually crt0.o or crt1.o), which is responsible for calling your main(). You can see what gcc is doing, when you add -v on the command line:
$ gcc -v -o test.exe test.o
crt0/crt1 does some setup and then calls into main. But the linker is finally responsible for building the executable according to the OS. With -v you can see also an option for the target system. In my case it's for Linux 64 bit: -m elf_x86_64. For your system this will be something like -m windows or -m mingw.
The error happens because you use these two options: -nodefaultlibs -nostdlib
These tell GCC that it should not link your code against libc.a/c.lib which contains the code which really calls main(). In a nutshell, every OS is slightly different and most of them don't care about C and main(). Each has their own special way to start a process and most of them are not compatible with the C API.
So the solution of the C developers was to put "glue code" into the C standard library libc.a which contains the interface which the OS expects, creates the standard C environment (setting up the memory allocation structures so malloc() will map the OS's memory management functions, set up stdio, etc) and eventually calls main()
For C developers, this means they get a libc.a for their OS (along with the compiler binaries) and they don't need to care about how the setup works.
Another source of confusion is the name of the reference. On most systems, the symbolic name of main() is _main (i.e. one underscore) while __main is the name of an internal function called by the setup code which eventually calls the real main()
I'm working on a library that must compile on linux and mac os X. Until now, I had no problem, compiling with "-g" worked well under both OS.
I tried to compile with some optimization ("-O2") and it works well under linux but I get an Undefined Symbol when I try to link a program with my library under mac os X.
Does anyone have any clue what I should look for?
nm mylib.a | grep _the_symbol
This returns same thing for linux and mac (no leading underscore under linux) :
154:00000018 C _the_symbol
377: U _the_symbol
Here is the compile line under linux for the program using the library:
/usr/bin/gcc -std=c99 CMakeFiles/prod-cons.dir/prod-cons.c.o -o prod-cons -rdynamic -L/home/claferri/dev/build/src ../src/libckaapi.a -lpthread -Wl,-rpath,/home/claferri/dev/build/src
And under mac :
/usr/bin/gcc -std=c99 -Wl,-search_paths_first -headerpad_max_install_names -fPIC CMakeFiles/prod-cons.dir/prod-cons.c.o -o prod-cons -L/Volumes/Data/claferri/Work/build/src ../src/libckaapi.a /usr/lib/libpthread.dylib
Here's a guess at a workaround: try building the library with the -fno-common flag. If you have multiple definitions of this variable, you'll need to add "extern" to all but one.
Note that the following is a guess, and I can't say for certain unless/until you provide the exact compiler flags you're using -- but Xcode defaults to setting -fvisibility=hidden, which would hide pretty much any symbol in your library, unless it's declared as visible.
You can do the same on Linux, but GCC's default is not to hide symbols.
You'll find more information here: http://gcc.gnu.org/wiki/Visibility