Question relates to the following build command which is part of a project I have inherited from a lost programmer who I can't ask to explain it. The project was based on the alsa utils 'latency' sample, which he has extended to provide other functionality. The command works on the project but I want to start stripping out all the unused junk in the project and I kind of need to understand whats going here. I can program C and use gcc in the basic sense but I don't understand the below command very well. I wonder if anyone can confirm my assumptions below and explain a couple of bits:
I have this command to build the project:
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -Wall -pipe -g -g -O2 -MT latency.o -MD -MP -MF ".deps/latency.Tpo" -c -o latency.o latency.c; then mv -f ".deps/latency.Tpo" ".deps/latency.Po"; else rm -f ".deps/latency.Tpo"; fi && /bin/bash ../libtool --tag=CC --mode=link gcc -lvgagl -lvga -Wall -pipe -g -g -O2 -o latency latency.o ../src/libasound.la
I think I understand whats going on here. Wall = warnings, pipe = irrelevant, -g = debugging stuff, -O2 optimization stuff, -MT make an object file instead of executable, and overall the first bit of the command means make a dependency list from latency.c, and also compile latency.o. The dependency file is to be called .deps/latency.Tpo.
If the first command returns success then move .deps/latency.Tpo to .deps/latency.po, if it returns failure delete .deps/latency.Tpo.
Then as long as the delete or move has succeeded, run the last bit (after the &&). Which links latency.o, ../src/libasound.la, lvgagl and lvga together into the executable latency.
Currently the project uses svgalib which I don't need it to do, so I will start by removing that, and I assume I can then remove the -lvgagl -lvga from the libtool command.
However I completely don't understand the '-DHAVE_CONFIG_H -I. -I. -I../include -I../include' portion. I know that -I is a header file search path but why is it repeated twice? And whats the DHAVE_CONFIG_H mean? And why bother making the dependency file if its not used again (I see no other references to it during the libtool step).
Most of that crap is automatically generated by automake and autoconf; you can ignore it.
The duplicated include paths do not hurt, so nobody bothered to avoid them.
The -DHAVE_CONFIG_H is generated by autoconf, but not used by any code in alsa-lib (nor by latency.c).
The only non-standard options in this are the -lvgagl -lvga libraries, which you already know how to handle.
Everything else can be ignored when moving to another build system; the defaults will work fine.
Related
This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Closed last year.
gcc -g -O2 -Wall -I/usr/local/include MyAddressBook.pb-c.c addressbooktest.c -lprotobuf-c -o test
worked, but
gcc -g -O2 -Wall -I/usr/local/include -lprotobuf-c -o addressbooktest addressbooktest.c MyAddressBook.pb-c.c
didn't.
man gcc said that
For the most part, the order you use doesn't matter.
Order does matter when you use several options of the same kind; for example, if you specify -L
more than once, the directories are searched in the order specified. Also, the placement of
the -l option is significant.
however I cannot understand how the use of -L and -l option change compile logic.
How can I know where to use -L, -l option?
When you use
gcc -g -O2 -Wall -I/usr/local/include -lprotobuf-c -o addressbooktest addressbooktest.c MyAddressBook.pb-c.c
the linker (which is a separate program which is invoked by the gcc front-end program) runs, it will find the library protobuf-c but since no one (yet) uses any functions from it, it will be ignored.
I'm quite frustrated. I'm trying to pass the name of the system configuration directory to a source file as a symbol. Some research on this very site gave me to understand that I should add the line
AM_CPPFLAGS = -DSYSCONFIR='$(sysconfdir)'
to my Makefile.am. I did so, and the define does show up in the invocation of gcc; in fact, here it is:
gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -DSYSCONFIR='/usr/etc' -g -O2 -MT perm.o -MD -MP -MF .deps/perm.Tpo -c -o perm.o ../../src/perm.c
The trouble is, gcc barfs anyway, telling me that SYSCONFDIR is undeclared.
I've got to be doing something wrong, but for the love of St. Gulik, I don't know what it is. My autoconf is 2.68, my automake is 1.11.3, my gcc is 4.6.3, and I'm trying to do this under Ubuntu 12.04.
A clean compile, a clean compile! My kingdom for a clean compile!
What you show looks like typo.
You are setting and passing SYSCONFIR which is not the same as SYSCONFDIR.
I'm trying to build a very simple C program for inclusion into a .deb package. The bulk of the project is in Python. When this program is included into a .deb package, lintian gives me the hardening-no-fortify-functions warning.
On further reading, it appears that Debian expects you to include certain flags while building C programs, and that these flags can be retrieved using dpkg-buildflags --get CFLAGS.
My initial build flags looked like this:
gcc -Wall -pedantic -o somefile somefile.c
Now, I'm building with
CFLAGS=`dpkg-buildflags --get CFLAGS`
gcc $CFLAGS -o somefile somefile.c
However, I continue to get the hardening-no-fortify-functions warning. What am I doing wrong here? Is this now a false positive? Can I just add an override and forget about it?
There are several possibilities of which the third seems most likely, but I've mentioned 1 and 2 in case they are causing you problems too:
dpkg-buildflags --get CFLAGS is returning the wrong thing. On my system it returns:
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
If you just execute it from the command line, what do you get?
Your value of CFLAGS is not being passed to gcc. I assume you are using a Makefile here; are those two statements actually adjacent? Do you not want CFLAGS = (with a space) if so? Or are you setting CFLAGS at the command line in which case you should know the debian build tool stuff strips the environment of most things that don't start DEB_, so you will need to set CFLAGS inside whatever builds the package.
The CFLAGS aren't sufficient to eliminate the hardening error. Let's have a look at the lintian error: http://lintian.debian.org/tags/hardening-no-fortify-functions.html and note it says 'Certainty: wild guess'. That does not inspire confidence that it is correct. However, I suspect the actual problem is this: you are not bringing in LDFLAGS. Try:
$ dpkg-buildflags --get LDFLAGS
-Wl,-Bsymbolic-functions -Wl,-z,relro
You'll need those on your linker line.
This approach would seem to work (i.e. at least compile):
gcc `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get LDFLAGS` main.c -o main
I'm new to makefiles, so I apologize in advance if this is a silly question. Also I removed most variables from my makefile because they weren't working properly (gnu make tells me that $(myvar) should be completely replaces by the value of myvar, however the output of make was showing me that this was not happening), so I apologize for the ugliness and the more than 80 character lines.
acolibobj = acoLibInit acoGlobalDefs
acolibinterface: $(acolibobj).o
acoLibInit.o:
gcc -fPIC -g -c -Wall -I/usr/include/dc1394 -o acoLibinit.o acoCommands/acoLibInterface/acoLibInit.c
acoGlobalDefs.o:
gcc -fPIC -g -c -Wall -I/usr/include/dc1394 -o acoGlobalDefs.o acoCommands/acoLibInterface/acoGlobalDefs.c
When I run this makefile I get:
gcc -fPIC -g -c -Wall -I/usr/include/dc1394 -o acoLibinit.o acoCommands/acoLibInterface/acoLibInit.c
cc acoLibInit.o -o acoLibInit
gcc: acoLibInit.o: No such file or directory
gcc: no input files
make: *** [acoLibInit] Error 1
So far as I can tell, what's happening is that make is trying to compile AND link, even though I explicitly added the -c flag. When I run "gcc -fPIC -g -c..." myself (from bash), I do not get any problems at all. Why does make go on to try "cc acoLibInit.o -o acolibInit"?
make is trying to build acoLibInit. It probably has built-in rule that specifies "whatever" can be produced by linking "whatever.o", which is why you get that cc line.
This line:
acolibinterface: $(acolibobj).o
expands to:
acolibinterface: acoLibInit acoGlobalDefs.o
(note the absence of .o on the first dependency). This is why it's trying to link acoLibInit.
Try this:
acolibinterface: $(addsuffix .o,$(acolibobj))
if you want only the .o files as dependencies for that target.
$(acolibobj).o expands to acoLibInit acoGlobalDefs.o. Thus, you're really saying:
acolibinterface: acoLibInit acoGlobalDefs.o
Simply define acolibobj = acoLibInit.o acoGlobalDefs.o and use acolibinterface: $(acolibobj).
I'm getting a totally bizzare error trying to compile a C program using GCC. Here is the batch file I am using:
echo Now compiling, assembling, and linking the core:
nasm -f aout -o start.o start.asm
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -I./include -c -o consoleio.o consoleio.c
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -I./include -c -o core.o core.c
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -I./include -c -o system.o system.c
ld -T link.ld -o core.bin start.o core.o system.o consoleio.o
echo Done!
concat.py
pause
Here are the error messages I am receiving when trying to run this code. All files are in the same directory, yes the PATH variable is set up correctly:
C:\Simple\core>build.bat
C:\Simple\core>echo Now compiling, assembling, and linking the core:
Now compiling, assembling, and linking the core:
C:\Simple\core>nasm -f aout -o start.o start.asm
C:\Simple\core>gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-func
tions -nostdinc -fno-builtin -I./include -c -o consoleio.o consoleio.c
The system cannot execute the specified program.
C:\Simple\core>gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-func
tions -nostdinc -fno-builtin -I./include -c -o core.o core.c
C:\Simple\core>gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-func
tions -nostdinc -fno-builtin -I./include -c -o system.o system.c
The system cannot execute the specified program.
C:\Simple\core>ld -T link.ld -o core.bin start.o core.o system.o consoleio.o
c:/djgpp/bin/ld.exe: system.o: No such file: No such file or directory (ENOENT)
C:\Simple\core>echo Done!
Done!
C:\Simple\core>concat.py
Traceback (most recent call last):
File "C:\Simple\core\concat.py", line 12, in <module>
with open("core.bin", "rb") as core:
IOError: [Errno 2] No such file or directory: 'core.bin'
Now, the interesting thing is the gcc command, which is the issue I'm having. (The other issues seem to be cascading from this.) When compiling core.c, the GCC command works just fine and great, and produces a .o file as expected. When attempting to compile system.c or consoleio.c, GCC fails, but in a very unexpected way: it appears as though windows cannot run the program. This makes zero sense to me. I've tried any number of things, including running these commands myself outside the window. Something about core.c is just special, and I can't figure out what the difference is. I literally copied that line and changed the filenames to create the other two lines that are failing.
So, in short, HELP. I'm using DJGPP and GCC on windows XP, along with a python script at the end that should tie everything together. (This all worked when the project was a single source file, but attempting to split the file into separate files has caused this strange error.)
Thanks.
PS: Yes, we are using a batch file, and I know that makes some of you cringe. However, I'd really like to understand this error before moving on to a makefile if possible. ^_^
EDIT: The accepted answer was indeed our problem, although the issue was with DJGPP, not Windows. (Windows doesn't seem to have a command limit.) The solution was to compile with MinGW instead of DJGPP, which fixed the issue right away. Thanks guys!
The line that works is 126 characters long, the others are 130 and 136 characters long. The problem is that there is a 127-character limit. I'm not sure how to get around this, but maybe make would get around it for you?...
Add -v to the gcc command line. gcc is in fact a driver, which runs several other auxiliary programs (tradicionally, the preprocessor, compiler, and assembler); -v makes it show their command lines as they are being executed, and also enables verbose mode. With this, you can see where it is failing.
As mentioned, DJGPP make (or Bash) or even a simple response file would solve this problem, so it's a non-issue. DJGPP is still plenty good as long for what it does. (P.S. Also see the ELF port or Japheth's HX mod.)