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.
Related
In my latest project I am encountering a strange issue regarding an undefined reference to a method of a shared library. I searched on SO but all I could find was either C++ related (extern "C") or not really helping.
The library in question is my fork of libosm which uses protobuf to generate de-/serialization code for OpenStreetMap data in its binary format (.osm.pbf). The function in question is osmpbf__blob__unpack but that is just the first I end up using so I suspect its a general problem.
I inspected the resulting libosm.a with nm and the method is there and exported but for some reason it is not found while linking. Below are my current flags. I tried changing the order and even including all libraries twice (as suggested in another thread) but I always end up with the undefined reference.
CFLAGS = -v -std=c99 -O3 -Wall -Wextra -pedantic
LIBFLAGS = -losmpbf -lprotobuf-c -lz -lpthread
At the moment I am quite lost on what the error could be, but I think it might be a minor general error. It has been a while since I used C..
Any help would be appreciated.
Cheers,
Florian
Edit: Here is my complete Makefile. I just made up the name for the variable LIBFLAGS since I use my own little rule but it seems like I should use LDLIBS and the builtin rules for this simple case.
CC = gcc
CFLAGS = -v -std=c99 -O3 -Wall -Wextra -pedantic
LIBFLAGS = -losmpbf -lprotobuf-c -lz -lpthread
all: main.x
main.x: main.c
$(CC) $(CFLAGS) $(LIBFLAGS) main.c -o main.x
clean:
rm -rf *.o main.x
The problem is the linker (gcc), like most linkers, processes the parameters from left to right. so the link sees the libraries, but there is no unresolved references to be handled, so nothing happens.
The fix is to place the libraries last on the line rather than just after the CFLAGS.
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.
My final executable (this is in unix though) will be proj07.
proj07: /user/cse320/Projects/project07.driver.o proj07.support.o
gcc -Wall /user/cse320/Projects/project07.driver.o proj07.support.o
proj07.support.o: proj07.support.c
gcc -c proj07.support.c
This creates proj07.support.o but no proj07 exists after compilation. I don't get an error so my mistake must be simple but I can't seem to figure it out.
Here's the output:
gcc -c proj07.support.c
gcc -Wall /user/cse320/Projects/project07.driver.o proj07.support.o
Also I am to use a static driver to test my file which is why the path is like that
You probably do have an a.out executable. Add -o $# to your first gcc occurrence and you should be fine.
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.)