In scons, how do you implement the --start-group and --end-group gcc flags? These should wrap a particular set of LIBS, but I couldn't find a PREFIX/SUFFIX option that wraps the entire (or partial set of) input to LIBS.
In case you're wondering what gcc flags I'm talking about, read more here:
GCC: what are the --start-group and --end-group command line options?
You're right that there is no built in prefix/suffix for this wrapper. The command line options specifying the list of libraries passed to the link command is computed based on the LIBS environment variable and stored in the _LIBFLAGS environment variable. _LIBFLAGS is then used as a part of the complete linker command line.
The defaults, defined in Tool/link.py in the SCons library, look something like:
env['LINKCOM'] = '$LINK -o $TARGET $LINKFLAGS $__RPATH $SOURCES $_LIBDIRFLAGS $_LIBFLAGS'
env['_LIBFLAGS']='${_stripixes(LIBLINKPREFIX, LIBS, LIBLINKSUFFIX, LIBPREFIXES, LIBSUFFIXES, __env__)}'
Assuming that you want to wrap the entire set of libraries, then in your environment, you can edit either the LINKCOM or the _LIBFLAGS variables to add the options:
# SConstruct
env = Environment(
CC = 'gcc',
LINKCOM = '$LINK -o $TARGET $LINKFLAGS $__RPATH $SOURCES $_LIBDIRFLAGS -Wl,--start-group $_LIBFLAGS -Wl,--end-group'
)
#env.Prepend(_LIBFLAGS="-Wl,--start-group ") # the trailing space is required
#env.Append(_LIBFLAGS=" -Wl,--end-group") # the leading space is required
env.Program('foo', ['foo.c'], LIBS='m')
I think editing LINKCOM is a little less invasive. In my trivial example, this generates:
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o foo.o -c foo.c
gcc -o foo foo.o -Wl,--start-group -lm -Wl,--end-group
scons: done building targets.
If you want to group just a subset of libraries, then you'll have to use separate LIBS variables for the "wrapped" and "unwrapped" libraries and duplicate the _LIBFLAGS function in a separate variable appended to LINKCOM.
Related
How to create a makefile for Linux for the next command?
gcc -shared -home/ time.c /libperi.a -o time.so
First, pick a name. This command appears to build time.so, so that's a good name.
The makefile is just a text file. Write it like this:
time.so:
gcc -shared -home/ time.c /libperi.a -o time.so
That whitespace before the gcc is a TAB, not spaces.
Once you have that working, you can read the manual and learn more about Make, which will allow you to write more powerful rules.
Here I am compiling a C code with the following Makefile.
MAIN:
g++ -c -o td.o -I/home/user/dp/pro/include td.c
g++ -c -o disk.o -I/home/user/dp/pro/include disk.c
g++ -o disk disk.o tds2.o -L ${DP_LIB} -L ${LIPN_LIB} -lgnb -lgtd -lnbl -lpin
./disk.exe RUN.dat
What is the purpose of -L ${DP_LIB} here? Precisely, I wish to know the function of ${}.
If it is linking a library, how is it different from -llib?
This makefile is by far very crude (I have seen bigger and better ones). I am new to makefiles, but atleast this one works.
The -L options is telling the linker to add a path to the list it uses to search for libraries. The ${DP_LIB} thing is how variables are used in makefiles. Presumably DP_LIB is a path to somewhere.
All this should be very clear if you just read the documentation and the actual makefile.
With -Ldir you specify a directory where the linker searches for libs. The lib files themselves are specified with the -llib argument.
Example:
-L/usr/X11R6/lib -lX11
means that the linker will look for libX11.so in /usr/X11R6/lib
(...and in other default places.)
gcc has -M-class options (-MMD, -MF, etc.) that allows to generate dependency file during compiling source file. The dependency file contains Makefile rules describing on which source files and headers the generated object file depends on. The dependency file may be included into Makefile and then make will automatically recompile source file when headers are changed.
I need a similar option but for generating dependency file during linking an executable. The dependency file should contain list of libraries used for linking an executable, so if any of libraries is updated, make will re-execute linking of the executable automatically.
I tried to use the same flags (-MMD, -MF), but they doesn't work for linking. It seems they are only for generating dependency files during compiling.
Is there any other flags or means for generating dependency file for executable?
So far I have not found dedicated gcc options for generating dependency file for executable, but found the --trace option (-Wl,--trace when used with gcc). This option generates list of libraries used during linking. Its output has the next format:
gcc -Wl,--trace myprog.c -o myprog -L. -lmylib
-lmylib (./libmylib.a)
-lgcc_s (/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/libgcc_s.so)
...
The list of libraries then may be converted to Makefile rules using sed:
echo "myprog: " > myprog.dep
gcc -Wl,--trace myprog.c -o myprog -L. -lmylib \
| sed -n 's/.*(\(.*\)).*/\1 \\/p' >> myprog.dep
So myprog.dep will have the following content:
myprog: \
./libmylib.a \
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/libgcc_s.so \
...
This dependency file may be included to Makefile and make will relink myprog if any of libraries are updated.
The dependency file doesn't contain list of object files, but the object files are usually known inside Makefile-script without help of compiler:
myprog: $(OBJS)
gcc -Wl,--trace $^ -o myprog -L. -lmylib | sed -n 's/.*(\(.*\)).*/\1 \\/p' >> myprog.dep
I read a lot of tutorials about CFLAGS and also looked in the official docs. Everywhere they say CFLAGS is implicit but still pass it explicitly in their example makefile to the compiler:
CFLAGS=-O2
gcc $(CFLAGS) -c foo.c -o foo.o
So, what does the term "implicit" mean in this context? If I declare CFLAGS=-O2 in my makefile and later just say gcc -c foo.c -o foo.o, will -O2 be active or not (so, is it really implicit)? If so, why do all tutorials (including official docs) still pass it explicitly in their examples?
Everywhere they say CFLAGS is implicit but still pass it explicitly in their example makefile to the compiler.
gcc does not use CFLAGS environment variable. See Environment Variables Affecting GCC.
CFLAGS is a conventional name for a Makefile variable with C-compiler flags and it is used by implicit make rules. See Variables Used by Implicit Rules for more details.
If you use your own make rules instead of the built-in ones, you do not need to use CFLAGS at all. Although it is a useful convention to do so because people are familiar with the conventional make variable names.
I believe CFLAGS is implicitly passed to the compiler command line by the makefile via the default compilation rule... Yet the CFLAGS can be overridden with custom flags so that each compilation command will take it and use.
You can test it easily:
$ cat cflags.mak
CFLAGS = -wrong
foo.o: foo.c
$ make -f cflags.mak
cc -wrong -c -o foo.o foo.c
cc: unrecognized option '-wrong'
So you can see it used the value of CFLAGS even though it was not explicitly specified in a rule; thus it is implicit.
But if you do specify your own rule for compiling .c files, you have to include it if you want it used:
$ cat cflags.mak
CFLAGS = -wrong
foo.o: foo.c
gcc -c $<
$ make -f cflags.mak
gcc -c foo.c
Here I provided my own rule for .c files which did not include CFLAGS, so CFLAGS was not used.
So the bottom line is if you rely on the built-in make rule for compiling .c files, CFLAGS will be included implicitly. But if you override that rule, you have to include it explicitly if you still want it to be used.
It means that there are implicit make rules, that use the CFLAGS, you can use.
So you can write a one line makefile with:
CFLAGS=-O2
if you later do:
make filename
(omitting extension) it will use an implicit rule that references the CFLAGS to convert you source file .c in an executable, so you don't need to write an explicit build statement for simple builds.
E.g. if you prepared a source name file.c it will build it with an implicit rule like:
$GCC $CFLAGS file.c -o file $LDFLAGS
see: GNU make documentation
I was trying to do something like this in a makefile:
program.exe: ui.o main.o
gcc ......etc
ui.o: window1.o window2.o
gcc -c window1.o window2.o -o ui.o #this doesn't want to work
window1.o: window1.c window1.h window1_events.c window1_controls.c ...
gcc -c window1.c window1_events.c window1_controls.c... -o window1.o
window2.o: ...
gcc ...
main.o: ...
gcc ...
but when I compile like this, it gives the error "input file unused because linking not done," and then I get a bunch of unresolved externs, etc--problems which are resolved by changing
program.exe: ui.o main.o
gcc ...
to
program.exe: window1.o window2.o main.o
gcc ...
so is it possible to just link object files together, to avoid having mile-long lines in a makefile and break down the build process a little more?
Yes: to merge several object files into one, use ld -r or ld -Ur:
From "man ld" on Linux:
-r
--relocatable
Generate relocatable output---i.e., generate an output file that can
in turn serve as input to ld. This is often called partial linking.
As a side effect, in environments that support standard Unix magic
numbers, this option also sets the output file’s magic number to
"OMAGIC".
If this option is not specified, an absolute file is produced.
When linking C++ programs, this option will not resolve references to
constructors; to do that, use -Ur.
You could also do this with gcc:
gcc -Wl,-r foo.o bar.o -o foobar.o -nostdlib
Merging object files like this has some advantages over using an archive library: if merged files change very infrequently (compared to say main.c), your final executable links will be faster.
OTOH, with archived library, the linker will only use what it needs, so your executable may end up being smaller if e.g. window2.c ends up not being necessary.
I bunch of object files is a library. You can create a library with the ar
utility. The following example creates a library called mylib.a containing the files foo.o and bar.o
ar rvs mylib.a foo.o bar.o
You can then link with it by using it on the compiler command line:
gcc -o myexe main.c mylib.a
To create a library:
ar rvs somelib.a file1.o file2.o file3.o
To link it:
gcc -o program.exe file4.o somelib.a