Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I am compiling my .so library code and came across a weird problem.
In one the the header file i have decleared a variable extern that is included in other .c file and not defined any where.
Code compiles fine and while runtime it gives error.
Why no error or warning at compile time ?
I am using gcc 9.
Use -Wl,--no-undefined and specify the libraries where your functions come from on the command line. For example, if library x uses functions defined in library y:
gcc -shared -o libx.so x.c # OK
gcc -shared -o libx.so x.c -Wl,--no-undefined # undefined symbols from lib y
gcc -shared -o libx.so x.c -ly -Wl,--no-undefined # OK again
Related
This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Compiling Fortran netCDF programs on Ubuntu
(2 answers)
Closed 4 years ago.
I want to compile some of my often-used Fortran code into a static library (assuming I would have access to both *.mod and *.a files).
This worked.
However, I have encountered the problem with linking.
Here is an example. Let's say I have mylib.f90 file:
MODULE MYLIB
IMPLICIT NONE
CONTAINS
INTEGER FUNCTION FOO(N)
INTEGER, INTENT(IN) :: N
FOO = N + 2
END FUNCTION FOO
END MODULE MYLIB
Which is compiled as
gfortran -c mylib.f90
ar rcs libmylib.a mylib.o
Now, I have a program that uses FOO function:
PROGRAM MYPROG
USE MYLIB
IMPLICIT NONE
INTEGER M
M = FOO(3)
WRITE (*,*) M
END PROGRAM MYPROG
For simplicity I put it in the same directory as mylib.mod and libmylib.a. Compilation:
gfortran -c myprog.f90
no issues. Linking, however results in error:
gfortran -L./ -lmylib myprog.o
myprog.o: In function `MAIN__': myprog.f90:(.text+0x11): undefined
reference to `__mylib_MOD_foo' collect2: error: ld returned 1 exit
status
However, symbol __mylib_MOD_foo is in libmylib.a:
nm libmylib.a
mylib.o:
0000000000000000 T __mylib_MOD_foo
and it compiles without a problem if I give it mylib.o. What am I doing wrong?
PS. I've seen somewhere, but can't find where now the way to link as follows:
gfortran -Wl,--whole-archive libmylib.a -Wl,--no-whole-archive myprog.o
It works. But it should solve the problem with weak symbols, whereas the output of nm didn't mark __mylib_MOD_foo as weak.
This question already has answers here:
How to remove unused C/C++ symbols with GCC and ld?
(11 answers)
Closed 6 years ago.
I need some help for compiling with GCC under MinGW.
Say I have two files:
File a.c contains two functions, a1 and a2
File b.c contains two functions, b1 and b2.
Then I link the two objects into a shared library. The command used are like:
gcc -c a.c
gcc -c b.c
gcc -shared -Wl, --version-script v.ver -Wl, -Map=out.map -Wl, --strip-all -o mydll.dll a.o b.o
File v.ver looks like:
mylib {
global: a1;
a2;
local: *;
}
which is used to control which functions to be exported.
By checking the mapfile I can see that the two functions in b.c are also included into the .text section of the DLL file.
Because this DLL file only exports a1 and a2, and b1 and b2 are only defined in b.c, but never used anywhere. Is there an option I could add in GCC or ld so that b1 and b2 are not built into the DLL file so that I can save some space in the DLL file?
Yes, this is possible. To do this, add the following two flags when compiling your C source code to objects:
-ffunction-sections -fdata-sections
This will generate bigger object files, but will add a lot of information for the linker.
When calling the linker add the following flag:
--gc-sections
The linker will now throw away all functions and sections that are not used. Note that this might incur a performance penalty:
Only use these options when there are significant benefits from doing
so. When you specify these options, the assembler and linker create
larger object and executable files and are also slower. These options
affect code generation. They prevent
optimizations by the compiler and assembler using relative locations inside a translation unit since the locations are unknown
until link time. An example of such an optimization is relaxing calls
to short call instructions.
(man gcc)
See also this question: Query on -ffunction-section & -fdata-sections options of gcc for more information.
in my homework i must use this command to compile my program:
gcc -o mtm_rentals -std=c99 -Wall -pedantic-errors -Werror -DNDEBUG mtm_ex2.c rentals.c list.c -L -lmtm
what i can change in that line are the files im writing after -DNDEBUG. when i do this the gcc says that there are undefined references to specific functions. now those functions are declared in an .h file and are implemented in a given file called libmtm.a
i concluded that it doesnt recognize libmtm.a, but our homework task says that the -lmtm flag(which is not declared anywhere) is supposed to link libmtm.a to the program.
what am i missing here? am i supposed to implement somehow the -lmtm flag?
thank you!
You are missing a . (single dot) behind the -L.
-lmtm will link against a libmtm library, this is correct. It's not an -lmtm flag, it's a -l flag concatenated with mtm, the library you want to link against. This library is searched in some predefined paths (like /usr/lib/) and additionally in the paths given by -L. Assuming libmtm lives in your current directory, you need to add that to -L, which is done with a ..
I'm using gcc 4.3.4 and ld 2.20.51 in Cygwin under Windows 7. Here's a simplified version of my problem:
foo.o contains function foo_bar() which calls bar() in bar.o
bar.o contains function bar()
main.c calls functions in foo.o, but foo_bar() is not in the call chain
If I try to compile main.c and link it to foo.o, I get an undefined reference to _foo_bar error from ld. As you can see from my Makefile except below, I've tried using flags for putting each function in its own section and having the linker discard unused sections.
COMPILE_CYGWIN = gcc -iquote$(INCDIR)
COMPILE = $(COMPILE_CYGWIN) -g -MMD -MP -Wall -ffunction-sections -Wl,-gc-sections $(DEFINE)
main_OBJECTS = main.o foo.o
main.exe : $(main_OBJECTS)
$(COMPILE) -o main.exe $(main_OBJECTS)
The function foo_bar() is a short function that provides a connection between two networking layers in a protocol stack. Some programs don't need it, so they won't link in the other object files related to the upper layer of the stack. It's a small function, and seems inappropriate to put it into its own .o file.
I don't understand why ld throws the error -- nothing is calling foo_bar(), so there's no need to include bar() in the final executable. A coworker has just told me that ld is not a "smart linker", so maybe what I'm trying to do isn't possible?
Unless the linker is from Cyberdyne Systems it has no way to know exactly which functions will actually be called. It only knows which ones are referenced. Even Skynet's linker can't predict what run-time decisions will be made or what will happen if you load a module dynamically at run-time and it starts calling various global functions1.
So, if you link in module m and it references function f, you will need to link with whatever module has f.
1. This problem is related to the Halting Problem and has been proven undecidable.
I hit the similar issue and I find this page:
http://lists.gnu.org/archive/html/bug-gnu-utils/2004-09/msg00098.html
Highligt:
The GNU linker still works at .o file granularity.
Gcc pulls in foo.o and then find bar() was undefined.
You'd better put foo_bar() into another .o file.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am really new to GCC and I don't know how to use it. I already have a copy of a pre-compiled gcc binaries I've downloaded from one of the mirror sites in the gcc website. Now, I don't know where to go from here. Please give me some tips on how I can proceed.
I am sorry for the rather vague question..
What I want are tips on how to use GCC. I've programmed in C in the past using the TC compiler. Thanks!
I really appreciate all of your suggestions. Thanks again.. :)
Use -Wall all the time.
Don't ignore warnings; fix them as they crop up.
Baby steps to start with.
Create the file you want to compile (hi.c) in your favorite editor, like:
#include <stdio.h>
int main (void) {
printf ("Hi there\n");
return 0;
}
Then from the command prompt, execute:
gcc -o hi hi.c
That will give you an executable you can then run.
Beyond that, it really depends on how much C (or C++ or other GCC language) you know. If you're a beginner at C, rather than just the GCC toolchain, get yourself a good beginner's book on the language and start reading. Most importantly, do the exercises, play with the code and so forth.
Based on your update that you're comfortable with C itself (the Borland line), you'll probably only be interested in the immediate GCC differences.
GCC is a command-line compiler. There are IDEs that use it but GCC itself is not an IDE. That means you'll probably be doing command-line compilation.
The basic forms of this are:
# creates an executable "exe" from your source file "src.c"
gcc -o exe src.c
# creates an executable "exe" from your source files "src.c" and "extra.c"
gcc -o exe src.c extra.c
# creates object files from your source files
gcc -c -o src.o src.c
gcc -c -o extra.o extra.c
# creates an executable file "exe" from your object files
gcc -o exe src.o extra.o
Once you get sick of doing that, you'll want to learn how to use make, a way of automating the build process with a file containing rules (dependencies and actions to take), such as:
all: exe
clean:
rm -rf exe src.o extra.o
rebuild: clean all
exe: src.o extra.o
gcc -o exe src.o extra.o
src.o: src.c
gcc -o src.o src.c
extra.o: extra.c
gcc -o extra.o extra.c
I don't do justice to the power of make here, it's far more expressive than it looks.
Unless you have no interest in portability, make sure you learn which features of GCC are GNU extensions to the standard. Granted, GCC is available on most machines, but it would usually be silly to restrict your code so it only compiles with GCC.
To that end, as well as the ubiquitous -Wall, I usually use -std=c99 (or -std=c89) with -pedantic. I like to work with -Wmissing-prototypes -Wstrict-prototypes to ensure that no functions are undeclared. Where the code is really clean, I will add -Wextra (more warnings than -Wall) and -Werror (treat warnings as errors). This makes sure that the code stays really clean - the compilation fails when there's a warning.
Makefiles are very helpful. You should definitely check out how to use them.